Use of std::strcmp at TGeo slows down DD4hep geometry construction

[SanghyunKo]

When placing volumes within DD4hep, dd4hep::volume::placeVolume (eventually TGeo of ROOT) uses std::strcmp to navigate around volumes. (dd4hep::Volume::placeVolume→TGeoVolume::_addNode→TGeoVolume::GetNode→TObjArray::FindObject→std::strcmp)

Usually, this does not cause any problem when the number of daughter volume is small. However, if the number of daughter volume exceeds around O(10000), it significantly slows down to O(h) of whole geometry contruction of DD4hep application.

There would be some way to improve this kind of behaviour since it does not happen in the standalone GEANT4.

[SanghyunKo]

To be clear, the use of std::strcmp itself is not a problem. However, it seems that somehow the complexity of the computation is not linear to the number of daughter volumes. I'll dig in and update the issue afterwards.

Edit: it turns out that the usage of std::strcmp is the main reason for slow down of DD4hep application (See slide 14-16 for the details [link]). For navigating geometry, DD4hep or TGeo uses std::strcmp while GEANT4 uses __gnu_cxx::__normal_iterator. Computing complexity of both methods are linear to (# of daughter volumes)^2. Still, there are almost O(100) differences between the cost of std::strcmp & __gnu_cxx::__normal_iterator.

[Chao1009]

We've encountered the same issue with implementing a detailed scintillating fiber detector (with over 100k fibers as daughter volumes). Any progress on this issue?

[SanghyunKo]

Hi @Chao1009, unfortunately not as far as I know. I made a presentation to DD4hep developers meeting last year, but it seems there is no easy solution since this is ROOT related problem.

FYI, a possible makeshift from the user's side for this problem (suggested at the meeting) is creating 'intermediate' volumes so that each volume does not contain a large number of daughter volumes.