LArSoft

The standard configuration of all LArSoft experiments' Geometry service loads the geometry from a GDML file.
This requires parsing the GDML file each time.
It is possible to save the parsed GDML into a ROOT file, and subsequently load it.
My unscientific test on a fast machine (woof.fnal.gov) shows that Geometry service in MicroBooNE takes 8-9 seconds to load. Loading the same GDML file from ROOT command line takes about 6 seconds; I assume Geometry uses the remaining 2-3 seconds to build its own representation of it. Loading the same geometry from a ROOT file takes less than half a second.

The potential gain of, say, 5 seconds is not relevant in production, but it may quite change the feeling when testing simple code interactively.

It would be good to explicitly support reading geometry from a ROOT file, and to establish a protocol for it.
An example could be:

1. get the ROOT file name from the configuration
2. replace .root with .gdml, learn if the matching GDML file exists
3. consistency check: if the GDML file exists:
   1. compute MD5 sum of the GDML file (this took negligible time, but it might be because in my test the O.S. had cached the file content already)
   2. compare it with the MD5 sum in the ROOT file
      • if the MD5 sum does not match, throw an exception: ROOT and GDML file are not consistent
      • if the ROOT file contains no MD5 sum, throw an exception: MD5 of the source GDML must travel with ROOT file
4. load the geometry from the ROOT file

If the specified file has a .gdml suffix, go straight to GDML file.

The gain in a machine where files are slow to fetch hasn't been checked. These files are relatively small, and ROOT file is about one fourth of the corresponding GDML.