KtLorentzVector in the current release (1.5) is a fairly simple extension of the CLHEP HepLorentzVector class and inherits its accessor method from the latter. In the case of ConeJet there is a need to access the eta-phi coordinates frequently, and repeated recalculation of these from the cartesian coordinates stored in HepLorentzVector slows down the code significantly.
Possible solutions include:
- Use a base class with virtual functions and a choice of implementations using cartesian or eta-phi coordinates. There will be some overhead due to virtual function calls. Should we still inherit from the CLHEP base class?
- Calculate eta, phi etc. when they are first required, caching the values for future calls. To keep the accessors const, the cached eta and phi variables should probably be mutable and the cartesian coordinates should always be the "master copy". There will be some overhead due to checking a flag on each call to check whether the values have already been calculated.
- Calculate eta, phi etc. when the 4-vector is constructed or has its values set. This will impose some overhead at construction time which is unnecessary in applications where only the cartesian coordinates are needed.
There is probably no ideal solution that is best in all cases. We should probably do some benchmarking to see how the various solutions perform in a variety of applications.