I profiled alcapana in preparation for another run to incorporate the muPC data. I processed the first 100 events of run 3738.
The MDQ_DigitizerOverflow uses almost 50% of the time. The breakdown for this function is
The majority of this is string functions (including 5.5% each of TH?::Fill functions). In total ~40% of the runtime is spent on string functions in this module, almost all stemming from their use as bin labels. If timing becomes an issue down the line, maybe we can use the flywheel method Ben introduced. Since maps are ordered, and fPulseIslandToChannelMap should be constant after the init phase, we can use the position in fPulseIslandToChannelMap for the bin number then label the bins in the eor phase.
I profiled alcapana in preparation for another run to incorporate the muPC data. I processed the first 100 events of run 3738.
The
MDQ_DigitizerOverflow
uses almost 50% of the time. The breakdown for this function isThe majority of this is string functions (including 5.5% each of
TH?::Fill
functions). In total ~40% of the runtime is spent on string functions in this module, almost all stemming from their use as bin labels. If timing becomes an issue down the line, maybe we can use the flywheel method Ben introduced. Since maps are ordered, andfPulseIslandToChannelMap
should be constant after the init phase, we can use the position infPulseIslandToChannelMap
for the bin number then label the bins in the eor phase.