as requested in Problem in read TTree ROOT, here is a dedicated thread about ROOT apps being slow to start up the first time around.
the setup (but as the numbers quoted in the original thread were obtained on the same machine, running on the same file albeit with different applications, I don’t think it’s a problem with the filesystem or the OS/architecture):
$> uname -a
Linux zoidberg 4.13.4-1-ARCH #1 SMP PREEMPT Thu Sep 28 08:39:52 CEST 2017 x86_64 GNU/Linux
$> root --version
------------------------------------------------------------
| Welcome to ROOT 6.10/06 http://root.cern.ch |
| (c) 1995-2017, The ROOT Team |
| Built for linuxx8664gcc |
| From tag v6-10-06, 19 September 2017 |
| Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
------------------------------------------------------------
$> gcc --version
gcc (GCC) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$> cat /etc/fstab |grep /home
/dev/sda4 /home btrfs rw,relatime,space_cache 0 0
it was compiled with this recipe on an ArchLinux 64b system:
One possible thing that definitely affects Python startup …
Two days ago I ran into a difference between (forked) cppyy and PyROOT: a certain class for which no dictionary was requested or created was available in the latter, but failed in the former. (To be specific, the problem was a base class of a class that was requested). A very interesting debugging session later, I found that looking for enums causes virtually all previously encountered headers to be loaded.
In pseudo-code, both do:
klass = FindClass(name) # fails on both
if (!klass)
resolved_name = Resolve(name) # calls IsEnum() in PyROOT only
klass = FindClass(resolved_name) # now succeeds in PyROOT, not in cppyy
In PyROOT, Resolve() checked for IsEnum(), but cppyy did not. (Yay for cleanup! Not!) The IsEnum() results in loading and JITing of the derived class’ header and all the other headers that brings in.
As it stands, I like the succeeding code better (it’s surprising not being able to instantiate a class, the derived, you requested a dictionary for) than the failing one, so I added IsEnum() into cppyy’s call. But this type of side-effect does cause a slow-down if it’s unnecessary, as it presumable is for rootls.
as I said in the original thread, note that the same behaviour happens with pure-C++ apps compiled against ROOT.
so most probably even if there is perhaps an issue wrt PyROOT (and python3?), it’s at worst an additional one.