Skip to content

Replace LArBadChannelMasker AlgTool with plain class

Walter Lampl requested to merge wlampl/athena:LArBadChannelMaskObj into master

While profiling the core-calo reconstruction with callgrind I noticed that the code to evaluate the 'badness' of LAr-Cells is relatively slow. The reason for this moderate hot-spot is that this piece of code is called very very frequently, roughly 1 million times per event. So small delays add up, like

  • vtable lookup going through the IAlgTool interface
  • de-ref'ing the ReadCondHandle(Key)
  • EventContext lookup

At the bottom of this long call-chain is a logical "and" of two bit-patterns, this is what we are interested in.

With this MR, the AlgTool LArBadChannelMasker is replaced by a plain class called LArBadChannelMask. Some of the functionality of the old AlgTools need to be absorbed by the client:

  • The ReadCondHandle(Key) to the LArBadChannelCont conditions object (pulled out of the loop over CaloCells)
  • The Property ProblemsToMask (vector of strings) that is then used to initialize the new LArBadChannelMask class.

I would really like to delete the old AlgTool, the name-similarity with the replacement class is potentally very confusing. That means I have to migrate the remaining 20 clients, some of which are utterly obsolete. For this reason, this MR is is a Draft.

One of the clients that puzzles me is the TrigT2CaloCommon/LArCellCont. It retrieves a public (default?) instance of the LArBadChannelMasker. It is unclear to me where this public AlgTool gets configured. A unconfigured default instance of the LArBadChannelMasker doesn't actually do any masking. Can we simply delete the masking option from the LArCellCont.cxx?

@damazio, any suggestion?

Edited by Walter Lampl

Merge request reports