[PWGHF] Cache prongs propagation in trackIndexSkimCreator - #17906

O2 linter results: ❌ 0 errors, ⚠️ 8 warnings, 🔕 7 disabled

Hi @fchinu , thanks for the development. I have a few doubts/questions.

• I don't see how the caching can help for two-prong candidates where there should be no duplicated calculation.
• For the three-prong candidates, it seems to me that you are calculating the track properties for all tracks upfront while the current implementation does the calculations only after applying the track selection.

Hi @vkucera, thanks for having a look! I would say that it helps also for 2 prongs, since the two loops are nested, and the negative prong information is extracted once per positive track.

Maybe I am missing something? For the 3 prongs, it is true that we calculate everything upfront without applying preselections, but it seems like that calculating the properties only once per collision is faster than once per triplet being built.
One thing worth mentioning is that the tests were ran by considering only Ds and D+, but I have now ran tests with all candidates and only for 2p, and there is an improvement in all the cases:
All channels: default: 3428s, cached: 1938s, ratio: 0.57
2P only: default: 727s cached: 569s, ratio: 0.78
As one would expect, the effect is smaller for 2p, since there is less combinatorics there, and the amount of duplicated work is lower, but in the end we produce derived data also considering 3p, where the effect is larger

Hi @fchinu , you are right, thanks for the clarification. Indeed, there is also duplication for the negative tracks in the 2-prong loop.
From the graphs, there seems to be no obvious memory increase, even though, AFAIU, you duplicate the grouped track table and the track-collision association table for each collision. If you can validate the output as well, it would be good to go.
Very nice improvement! Thanks again!

Thanks a lot @vkucera for approving the PR! For bookkeeping I write here what we discussed earlier:
The outputs are validated, and show no difference in the tables produced by the track index skim creator. Indeed, it is very nice to see that there is no visible increase in memory consumption, maybe that could be due to how tracks retrieval from the tables is performed in the framework, though I'm not fully sure

@fgrosa Please don't enable the auto-merge before the tests finish. Now the result of the code check cannot be reported.