Optimizations in the CM tracker

[iouribelikov]

This PR contains a couple of fixes and optimizations that improve the performance of the Cooked Matrix tracker ( see https://indico.cern.ch/event/792935/ )

[matthiasrichter]

Please use a more descriptive variable name, e.g. labelMap, labelUsage, labelOccurence, also to make sure not to be mixed with the type.

[iouribelikov]

@matthiasrichter Thank you very much, Matthias, for checking this piece of my code.
You are certainly right: this map is actually "labelOccurence". Fixed.

[matthiasrichter]

do you want to change also kRoadY to float for consistency? Maybe you can also add a comment about the changed value. Is this because the inclination of the track is taken into account to calculate an effective value?

[iouribelikov]

In fact, all these parameters should now in O2 become "float". (This is because our "base track" is made of floats). Fixed as well !
Yes, the initial value was changed, because this "road" now becomes a function of the
track inclination angle.

[matthiasrichter]

One could also consider to use std::unordered_map instead of std::map, this has a faster per-element access. Can be done after #1645 has been merged (otherwise a separate hasher functor would be required to define use unordered_map with MCCompLabel).

[shahor02]

One could also consider to use std::unordered_map instead of std::map, this has a faster per-element..
@matthiasrichter please note that in other occasion we had to change the std::unordered_map to std::map, since the former was producing an error on the MacOS when building the root dictionary, this should be a root bug: #1171 (comment)

[shahor02]

it is better to use const Point3Df& txyz2 here.

[shahor02]

Why do you still use doubles here?
Just for the info: the file O2/Common/MathUtils/include/MathUtils/Utils.h provides a set of methods for dealing with angle wrapping, including the BringTo02Pi

[iouribelikov]

@shahor02 Thank you, Ruben, for the suggestions.
Actually, I have found one more place like that. All are fixed now.

[shahor02]

just small comments below:

[matthiasrichter]

@shahor02 Hi Ruben, ah interesting. Though here it concerns a local variable in a function implemented in cxx file. So I suppose root dictionary generation would not tough it. But good to know.

[iouribelikov]

@matthiasrichter @shahor02 Hi Matthias, Ruben. Asking your opinion about the std::map.
Naively, I would think that a "map" should be faster than an "unordered map" for numeric entries (like in this function). Especially, in the case of a few entries only (here: not more than 14).
Because, no hashing would a priori be needed "behind the scene" ...

[shahor02]

@iouribelikov in general, the unordered_map is more efficient, the only advantage std:map gives you is sorted order of the iteration. Hashing is const time operation, while std:map needs to rebalance the tree at every insertion, which is log(n) operation. But in practice, difficult to say w/o real benchmarking which one is faster for the relevant range of the n.

[iouribelikov]

@shahor02 Thank you. Always good to learn something new.
On the practical side, I have now checked it with a profiler: the cookLabel function takes 0.8% of the tracking time (if running in a single thread). So, here, we should be fine with any choice of the map flavour.