ATLASRECTS-6783 TRTRawDataProvider: Use DataPool for the offline case

TRTRawDataProvider: Use DataPool for the offline data case

This is a follow-up of past MRs on using data pools

The more relevant would be MR !62116 (merged) MR !62369 (merged) reco on MC and Overlay.

We seem we do many small allocation (Number 1 in my Q442 heaptrack test)

MOST CALLS TO ALLOCATION FUNCTIONS                                              
 14226185 calls to allocation functions with 5.42M peak consumption from         
 TRT_RodDecoder::int_fillFullCompress(eformat::ROBFragment<> const*, InDetRawDataContainer<>*, TRT_RodDecoder::t_CompressTable const&, std::vector<> const*) const
 at /build/atnight/localbuilds/nightlies/Athena/23.0/athena/InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRT_RodDecoder.cxx:1187
 in /cvmfs/atlas-nightlies.cern.ch/repo/sw/23.0_Athena_x86_64-centos7-gcc11-opt/2023-04-08T2101/Athena/23.0.24/InstallArea/x86_64-centos7-gcc11-opt/lib/libTRT_RawDataByteStreamCnv.so
14226185 calls with 5.42M peak consumption from:                                
TRT_RodDecoder::fillCollection(eformat::ROBFragment<> const*, InDetRawDataContainer<>*, TRT_BSErrContainer*, std::vector<> const*) const
at /build/atnight/localbuilds/nightlies/Athena/23.0/athena/InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRT_RodDecoder.cxx:297
in /cvmfs/atlas-nightlies.cern.ch/repo/sw/23.0_Athena_x86_64-centos7-gcc11-opt/2023-04-08T2101/Athena/23.0.24/InstallArea/x86_64-centos7-gcc11-opt/lib/libTRT_RawDataByteStreamCnv.so
TRTRawDataProviderTool::convert(std::vector<> const&, InDetRawDataContainer<>*, TRT_BSErrContainer*, EventContext const&) const
 at /build/atnight/localbuilds/nightlies/Athena/23.0/athena/InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRTRawDataProviderTool.cxx:121
in /cvmfs/atlas-nightlies.cern.ch/repo/sw/23.0_Athena_x86_64-centos7-gcc11-opt/2023-04-08T2101/Athena/23.0.24/InstallArea/x86_64-centos7-gcc11-opt/lib/libTRT_RawDataByteStreamCnv.so
TRTRawDataProvider::execute(EventContext const&) const                      
at /build/atnight/localbuilds/nightlies/Athena/23.0/athena/InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRTRawDataProvider.cxx:129
in /cvmfs/atlas-nightlies.cern.ch/repo/sw/23.0_Athena_x86_64-centos7-gcc11-opt/2023-04-08T2101/Athena/23.0.24/InstallArea/x86_64-centos7-gcc11-opt/lib/libTRT_RawDataByteStreamCnv.so
Gaudi::Algorithm::sysExecute(EventContext const&)                           

In the other cases the improvements on cpu were not only in the producer side, but in access and also for deleting the elements at the end of the event.

Ping @jchapman and @ssnyder

Also ping @abarton , but mainly for the thing that is not happening here i.e I am not touching the online case ...

changed the description

This merge request affects 1 package:

• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv

This merge request affects 9 files:

• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/CMakeLists.txt
• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/TRT_RawDataByteStreamCnv/ITRTRawDataProviderTool.h
• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/TRT_RawDataByteStreamCnv/ITRT_RodDecoder.h
• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRTRawDataProvider.cxx
• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRTRawDataProvider.h
• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRTRawDataProviderTool.cxx
• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRTRawDataProviderTool.h
• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRT_RodDecoder.cxx
• InnerDetector/InDetEventCnv/TRT_RawDataByteStreamCnv/src/TRT_RodDecoder.h

Adding @cgrefe ,@calfayan ,@sroe ,@goetz as watchers

changed the description

added 23.0 InnerDetector review-pending-level-1 labels

From a design principle I always wanted to hide the divergence between the online and offline case as much as possible. While I don't understand how the datapools work, is there a reason we can't use them in online?

Hey,

I need to understand how/what you cache and how add-with-locks works in this (online) context.

Although is hidden , there kind of 2 paths I could kind of see depending on this extra cache.

The dataPool is get cleaned up via the SGImplSvc look MR !62764 (merged) (as the printous are close to where is handled). And you could think it as a per thread thing [https://gitlab.cern.ch/atlas/athena/-/blob/23.0/Control/AthAllocators/AthAllocators/DataPool.h].

I do not know how often you will create the elements and then delete them if ever. what assumption are there if any ? And how exactly the views are handled in the store. Also was not sure if I was missing something else.

There is case one could use it there easily, but I will need to read and wanted to see the gains.

My options :

• If i wrap my head around the views could try it here already
• If this one works/ gives gains I will try it also for online in a CI in a separate MR. And worse come to worse I break things and ask you there concretely.
• If this one does not work there is no discussion .

CI Result SUCCESS (hash 71c67c1e)

	Athena
externals
cmake
make
tests

Full details available on this CI monitor view. Check the JIRA CI status board for known problems
Athena: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 72946]

resolved all threads

changed the description

Looks good, approving - L1

added review-approved label and removed review-pending-level-1 label

added review-approved-tier0 label

added review-approved-point1 label

mentioned in commit 43b35429

merged

mentioned in merge request !63810 (merged)

And then various things using this input and the creator alg.

And I would assume since delete is much faster the incident

mentioned in merge request !63871 (merged)

mentioned in merge request !63914 (merged)

mentioned in merge request !63916 (merged)

changed title from TRTRawDataProvider: Use DataPool for the offline case to ATLASRECTS-6783 TRTRawDataProvider: Use DataPool for the offline case