The implementation of G4SDStructure stores the structures and detectors in std::vector, a sequential container. Since this class is mostly doing lookups in these containers (on their G4String name) in the methods FindSubDirectory and GetSD, it is more logical to use an associative container, e.g. a std::map with the name as key: std::map<G4String,G4SDStructure*> This will increase the memory overhead a bit but will greatly reduce the CPU-load from N^2 to N*logN string comparisons, where N is the size of the containers. Note that the search/(remove)/insert idiom can all be done with a map by searching once. For some of our studies the number of sensitive detectors can be quite large and the initialisation time becomes significant.
It is a surprise to me that you reported this method dominated the processing time of the first event. I expect you are aware that one sensitive detector object could be assigned to any number of logical volumes. Even for the ATLAS detector the number of sensitive detector objects are rather small. How many sensitive detectors do you have? Could you please explain your use-case? Makoto
Thanks for your comment. We typically define a unique sensitive detector per logical volume indeed. We will look into your proposed solution and see if that is feasible for our application (LHC simulation study). I will come back to you.
We have adapted our code and your solution works well. Many thanks for your help. Nevertheless I feel that the implementation of the SDStructure could be improved but I understand that it might not be worth the effort. Feel free to close as won't fix or equivalent.
