Reading every library in `LD_LIBRARY_PATH` when using Python

[jmcarcell]

I have observed that when doing certain things in python, every library found in LD_LIBRARY_PATH (and also including /usr/lib) will be read. To reproduce (with EDM4hep):

strace -e open,openat,creat python -c "import edm4hep; edm4hep.CaloHitContribution();" 2>&1 | wc -l

gives ~20k lines and if one inspects the output, it's opening every library. A similar issue has been reported before in ROOT:
root-project/root#14277. The result is a slower startup time, in particular when using CVMFS it takes much longer since I believe all the libraries have to be downloaded. I can reproduce locally, with the Key4hep stack and also with the LCG stack.

Further debugging hints that it is the ::typeName symbol that is not being found by Cling, triggering the search. Indeed, by removing static constexpr from

podio/python/templates/Object.h.jinja2

Line 57 in aa5927b

static constexpr std::string_view typeName = "{{ class.full_type }}";

and removing the code that uses typeName in LinkCollectionImpl.h this is fixed.

For EDM4hep, I checked with a for loop for which objects this search is triggered (object and line count of strace):

EventHeader 19371
MCParticle 2007
SimTrackerHit 2007
CaloHitContribution 19370
SimCalorimeterHit 2007
RawCalorimeterHit 19370
CalorimeterHit 2007
ParticleID 19370
Cluster 2007
TrackerHit3D 19370
TrackerHitPlane 19370
RawTimeSeries 19370
Track 2007
Vertex 2007
ReconstructedParticle 2007
TimeSeries 19370
RecDqdx 19370
GeneratorEventParameters 19370
GeneratorPdfInfo 19370
RecoMCParticleLink 1814
CaloHitMCParticleLink 1814
ClusterMCParticleLink 1814
TrackMCParticleLink 1814
CaloHitSimCaloHitLink 1814
TrackerHitSimTrackerHitLink 1814
VertexRecoParticleLink 1814

It seems those that have a Link do not have this problem? Maybe because of some include?

For some it is working fine (~2k files opened) but for others it is reading every library (~20k files opened on my machine).

the for loop:

for class in EventHeader MCParticle SimTrackerHit CaloHitContribution SimCalorimeterHit RawCalorimeterHit CalorimeterHit ParticleID Cluster TrackerHit3D TrackerHitPlane RawTimeSeries Track Vertex ReconstructedParticle TimeSeries RecDqdx GeneratorEventParameters GeneratorPdfInfo RecoMCParticleLink CaloHitMCParticleLink ClusterMCParticleLink TrackMCParticleLink CaloHitSimCaloHitLink TrackerHitSimTrackerHitLink VertexRecoParticleLink; do
    echo $class $(strace -e open,openat,creat python -c "import edm4hep; edm4hep.$class()" 2>&1 | wc -l)
done

It seems this has been happening for a while. Currently, I think it was introduced when typeName was added. But before that, build_version was not being found and it would also trigger this search (and an error in debug builds: key4hep/key4hep-spack#670).

I haven't found any workarounds other than the one above about removing the usage of typeName from collections in LinkCollectionImpl.h.

I'll report this to ROOT to see if we can find a fix.

[jmcarcell]

I tested if this had anything to do with links, and creating a Link between classes that have this problem fixes it (for example a Link between edm4hep::EventHeader and edm4hep::CaloHitContribution. I think this is because ::typeName is being used in

podio/include/podio/detail/LinkCollectionImpl.h

Lines 216 to 219 in 5b73297

	constexpr static std::string_view typeName =
	podio::utils::static_concatenate_v<podio::detail::link_coll_name_prefix, FromT::typeName,
	podio::detail::link_name_infix, ToT::typeName,
	podio::detail::link_name_suffix>;

, so I came up with the workaround in #775.

[tmadlener]

Shall we close this now that #775 has been merged, or keep this open to remind us of the fact that is at the moment mainly a workaround?

[jmcarcell]

After it is fixed on ROOT we can have a preprocessor check to remove the workaround I guess. Even nicer would be to remove it completely from the generated file by checking the version of ROOT but this would require some work I think. So I don't know what we want to do with that. Maybe leave open and we add a preprocessor check when it is fixed in ROOT.

[jmcarcell]

I just noticed that doing:

$ strace -e open,openat,creat python -c "import edm4hep; edm4hep.MCParticleCollection()" 2>&1 | wc -l
21566

using the Key4hep stack but also the LCG stack on Alma 9, so again opening every library that can be found. So this is not solved for collections. Interestingly, unlike before, I can not reproduce locally with the same version of ROOT, which is probably why this wasn't caught when I was working on the workaround.

[tmadlener]

Closing this for now as #808 seems to have addressed the remaining issue for the largest part.