Large-ntuple reorganisation: performance issue

ROOT
1

Hi all,

I need to reorganise a large ntuple and my straight-forward implementation gives a poor performance. I would be happy for any hint how to improve it.

I have a large ntuple split into about 10 ROOT files. Each of the files is stored on EOS, has about 5 GB and 3 M events. Later, I’d need to consider event larger ntuples: with about 100 such ROOT files. The reorganisation I’m interested in applies a mapping and combines data from some branches in a file and in an event with data from other branches in another file and another event. The output is a ntuple with exactly the same structure as the input one.

I’ve attached my simple implementation. Basically, it loads all the TTree’s in the beginning and then traverses the mapping, using SetBranchStatus to load appropriate branches from appropriate tree/events. Each recombined event is “Filled” into the output TTree. Running the code on LXPLUS, 50 events and with reduced list of branches gives this timing characteristics:

real	2m43.210s
user	0m5.630s
sys	0m3.062s

which essentially exclude using this approach.

Many thanks in advance for your tips,

Jan.
recombine.cc (3.22 KB)

2

Hi Jan,

The ‘issue’ is likely that you are reading each TTree in random order of entries possibly resulting in the reading from the server and the decompression of the same data many times. If this is the case, sorting the entries in increasing order (for each indiviudal TTree) should solve the problem. … If the intent is to shuffle the entries then the ‘only’ way to reduce the run-time is to load all the TTree data in memory … assuming you have enough RAM.

Cheers,
Philippe.

3

Hi,

to add a comment to the complete answer of Philippe, lxplus machines do not deliver constant (high) performance since they are virtual nodes. It might be useful to repeat the test on a physical (preferably empty) node before detailed performance considerations.

Cheers,
Danilo