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>
.