Hi Anton and Rene, Rene Brun wrote: > Hi Anton, > > KOSU_FOKIN@garbo.lucas.lu.se wrote: > > > > Hi Rene, > > > > perhaps I wrote a bit missleading message. No, I do not call autosave > > after each event but rather after a predefined number of events set by > > a user. What I wanted to say tis that at high event rates I update > > event file quite frequently and it causes collisions. > > > Instead of AutoSaving after a fixed number of events, I have found it to be more efficient to use the TTree::SetAutoSave method to request an automatic AutoSave after a set amount of data has been dumped to disk by the baskets which have become full. The reason this is more efficient is that it takes advantage of the fact that AutoSave won't rewrite the information that has already been dumped by full baskets, and so there are fewer buffers still in memory which AutoSave must write out immediately after the basket dumps. > > Well, this is your choice. Choose an update frequency that does not penalize > your application, still preserving security. > > > I do know that autosave as well as TFile::Write() is a very time > > consuming procedure. On the other hand what I want to do is to > > write and physically flush the latest hundred events at the end > > of an existing file. Why it is so time consuming? Also ... I have > > noticed that it slows down with file size growing. In our cases > > (with Susan) we do not want to overwrite the whole file or do something > > except writing things at the end of file. How can we do so? > > > > AutoSave writes a copy of the Tree header + all the branch buffers. > If you have many branches and/or large buffer sizes, the amount of I/O > per AutoSave can be large. For example, if you have a Tree with 100 branches, > each with 32K, you have to write the compressed result of these buffers. > Could be 3.2 MBytes. > > Autosave time should not grow with the file size. You must have something else > happening! Could you send me the output of tree->Print() > and also of gDirectory->ls() ? > I also observe what I think is an increase in time spent AutoSaving as the number of events increases, at least when running with compression level=1. I think this is just because the Tree buffers still in memory as the number of entries increases are fuller. My solution to this has been to not allow the basket sizes to be too big (but you don't want to make them too small either due to size and read performance issues - there has to be a compromise). There was some discussion of this issue of optimizing the performance of AutoSave on an earlier posting: http://root.cern.ch/root/roottalk/roottalk99/2564.html Rene, at that time you suggested providing a method of automatically tuning the basket size to optimize the performance with AutoSave. Did anything come of that? I think that this would be extremely useful. Sue Kasahara
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:35 MET