Hi,
For some experiment I created a tree with around 3e+6 entries. I also wrote a script that would take a kind of random entry and read it out. I noticed this process was going slow for entries around some entry number. I used the speed.C described by Axel ( [url]Locate like command ) to see if this slow speed was due to my script or due to my tree, and at some interval it became slow (instead of the normal 3e6 entries/s it was now1e4entries/s, quite a decrease). I narrowed down the interval speed.c was computing and decreased the time steps as well, so eventually I found a single entry that seemed to cause all my problems: it had a speed of 1,4 entries/s.
So I decided to see what happened if I skipped this entry in speed.C, but if I did this, the entry following this one would become really slow. So that didn’t work.
The idea arose that perhaps the tree was compressed in multiple parts (I don’t know the correct terms for this) and that root would have to unpack a new part of the tree or something like that. I checked this idea by creating a much larger tree (file of 700mb instead of the 36 mb for the situation above) and run speed.C over it. Now it turned out that there were many of these events that were very slow, distributed quite periodically over the file. I tried it on a different computer here and the same entry gave me trouble, but when I sent the file to someone on the other side of the globe, he did not experience any slow entries.
So my question: does ROOT read out a tree in batches and is this slow read-out rate due to storing another part of the tree in the memory? Or is the file written in different ‘parts’ that have to be unpacked seperately?
I would really like to get rid of this slow entry, since it seems to be the single thing that slows down my simulation tremendously. Thank you in advance!
Best regards,
Mart