ROOT apps slow startup

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:

here is the strace of:

$> strace rootls -t some.root |& tee strace.txt

strace.txt (800.0 KB)

you’ll see that a bunch of ROOT headers are being stat-ed for some reason.

Thanks! Can you re-do the stat with (if possible relative) timing info?

@dpiparo if you have a chance to look at this while I’m gone that’d be great - if not I’ll have a look when I’m back!

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.

here they are:

rootls-strace-fast.txt (746.7 KB)
rootls-strace-slow.txt (749.3 KB)

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.

just to decouple the issues, here are the straces of a simple C++ program I used for my benchmarks for my ACAT paper:

read-strace-fast.txt (802.1 KB)
read-strace-slow.txt (803.7 KB)

with the ancillary files to generate the binaries:

read-data.cxx (727 Bytes)
gen-data.cxx (683 Bytes)
Makefile.txt (1.7 KB)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.