Hi Volker,
We are also playing with the use of TTree::AutoSave within the context
of a data model in which we hope to be able to read event data from
a ROOT file before the file has been closed by the writing process.
In my experiments with TTree::AutoSave (in root v2.22) so far, I have found
that:
1)Using a gDirectory->Purge() after the AutoSave will get rid of previously
AutoSave'd trees and keep the output file size small. The sequence is:
tree -> AutoSave(); //Call AutoSave to save the tree to disk
gDirectory -> Purge(); //Purge old trees
Rene's modification to TTree::AutoSave in version 2.23/08 of ROOT
however makes the Purge unnecessary.
2)As Rene suggests, tuning helps in the determination of when and how
often to AutoSave the tree. Something that was not clear to me at
first was that using the TTree::SetAutoSave mechanism, e.g.
tree -> SetAutoSave(1000000); //AutoSave after every 1 Mbyte written to disk
will invoke AutoSave after the specified number of bytes (1 Mbyte in
this example) are written to disk by basket dumps, and NOT after
1 Mbyte of data has been filled in the tree.
Thus the frequency of AutoSave's using the SetAutoSave mechanism is
directly tied to the basketsize set in the tree branch definition.
TTree::AutoSave will not rewrite information which has already been
dumped to disk by basket dumps. Tuning the SetAutoSave and basket
size parameters so that the largest baskets are dumped to disk just
before AutoSave is invoked saves a lot of processing time.
Good luck with your work,
Sue Kasahara
p.s. If anybody else has experimented with AutoSave and has tips on how
to optimize its use, I'd like to hear about it.
Rene Brun wrote:
> Hi Volker,
> In the coming 2.23/08 I have modified TTree::AutoSave to
> automatically delete the previously saved tree header once the new
> one has been written. I have also removed the print statement.
>
> Note that calling TTree::AutoSave too frequently (or similarly
> calling TTree::SetAutoSave with a small value) is an expensive
> operation. You should make tests for your own application to find a
> compromize between speed and the quantity of information you may
> lose in case of a job crash.
> Rene Brun
> Volker Boerchers wrote:
>
> > > The TTree::AutoSave function saves the Tree header in memory
> > > including:
> > > - the branches/leaves data structure
> > > - the branch buffers in memory
> > >
> > > Depending the number of branches in your tree and the branch
> > > buffer size the space occupied by the Tree header may be non-
> > > negligible. It must be bigger than the size of one single event.
> > > It does not make sense to call this function after each Fill.
> > > The intented use is to save at regular intervals depending on:
> > > - how much data has been written so far on disk
> > > - how many cpu/rt seconds used since the last autosave
> >
> > in our case the fill happens only once after each event (which
> > takes a lot of cpu time). So this is actually a good occasion for a
> > save (perhaps only after each n'th event).
>
> > > Currently AutoSave does not delete the Tree headers on disk
> > > generated by previous Autosave. If you have too many Autosave,
> > > you will get (what you found) many Tree headers and the space can
> > > be much bigger than the useful data.
> > > I could implement an automatic delete of the previous AutoSave
> > > once the current Autosave has successfully completed.
> >
> > This would be a great improvement IMHO because older AutoSave data
> > is of no use, right? In the meanwhile, can I do the deletion `by
> > hand'? (I can't, I suppose...)
> >
> > Regards,
> > Volker
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:42 MET