Skip to content

Evaluate replacing ECAL CalibratedClusterPtr with CalibratedPFCluster #38059

Open
@fwyzard

Description

@fwyzard

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions