-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Description
The PFECALSuperClusterAlgo class uses internally a CalibratedPFCluster class which is a wrapper around an edm::Ptr<reco::PFCluster>:
class CalibratedPFCluster {
public:
CalibratedPFCluster(const edm::Ptr<reco::PFCluster>& p) : cluptr(p) {}
double energy() const { return cluptr->correctedEnergy(); }
double energy_nocalib() const { return cluptr->energy(); }
double eta() const { return cluptr->positionREP().eta(); }
double phi() const { return cluptr->positionREP().phi(); }
edm::Ptr<reco::PFCluster> the_ptr() const { return cluptr; }
private:
edm::Ptr<reco::PFCluster> cluptr;
};As well as a shared_ptr<...> and a vector<shared_ptr<...>> types:
typedef std::shared_ptr<CalibratedPFCluster> CalibratedClusterPtr;
typedef std::vector<CalibratedClusterPtr> CalibratedClusterPtrVector;The use of what are essentially a shared_ptr<Ptr<T>> and vector<shared_ptr<Ptr<T>>> seems inefficient, given that edm::Ptr<T> is a lightweight object which should be used by value.
In addition, the use of std::vector<std::shared_ptr<CalibratedPFCluster>> could be replaced by the much more efficient edm::PtrVector<T>.
The use of these non optimal data structures is exacerbated by #37115, which introduces and uses
typedef std::vector<std::pair<CalibratedClusterPtr, CalibratedClusterPtrVector>> EcalGraphOutput;vs the more compact
typedef std::vector<std::pair<edm::Ptr<reco::PFCluster>, edm::PtrVector<reco::PFCluster>>> EcalGraphOutput;I would suggest to study the impact of replacing CalibratedClusterPtr with just CalibratedPFCluster, and of reworking the interface to support using edm::PtrVector<reco::PFCluster>.