Re: TTree::AutoSave()

Rene Brun wrote:
> It looks like your Tree has a small number of entries and all entries
> fit in memory in the branch buffers,

I don't know. The file without calls to AutoSave() is 326 kbytes, with a dozen calls is 589 kbytes -- clearly small enough to fit in memory. This is 1,000 events.

> or more entries but with very large buffer sizes. I can tell you more if
> you send the result of TTree::Print.

Well, I'm removing the calls to AutoSave(), as in practice it's easier to re-run a crashed job than to deal with the hassle. My users are non-experts, and having two copies of every TNtuple is confusing.

Is there really no way to "checkpoint" all of the TTree-s (or TNtuple-s) in a TFile so that if the program crashes the file can be opened and used up to the last checkpoint? Without keeping a second copy of all the data or a second version of each TTree.

> Note that, in general, it is a very bad idea to have many Trees in the
> same file. It is more efficient
> to have one single Tree with more branches.

This is a Geant4 simulation that was based on HistoScope (now defunct). It generates 17 different TNtuples, and they cannot be combined; we find it more convenient to have 1 root file than 17. I have written a Root macro that essentially performs the duties of the old "histo" program (i.e. easily and interactively generate histograms from TNtuples, with sliders for cuts). Efficiency is not a problem, as even a 250k event TNtuple can be re-scanned as I move a slider without undue delay (it's great to have such computing power in a laptop!).

Tom Roberts

>
> Rene Brun
>
>
> Tom Roberts wrote:

>> When I use TTree::Autosave() on a tree in a TFile, I get two copies of 
>> the TTree as expected (different versions), but the file is roughly 
>> twice as large. As I am making files that are quite large, doubling 
>> their size is not acceptable. Note my TFile contains many TTree-s, and 
>> I call AutoSave() on all of them every N events (N=100000 by default).
>>
>> Is there any other way to "checkpoint" the output file so if the 
>> generating program crashes I can still recover most of the data that 
>> was written to the .root file, without doubling the size of the file?
>>
>> In a related question: how does TFile::Flush() relate to such 
>> "checkpoints"? My guess is that partly filled buffers of the TTree are 
>> not written to disk, and for consistency this really needs to happen 
>> at the TTree level, not the TFile level.
>>
>>
>> Tom Roberts