Pasha Murat wrote: > > Hello , > > I'm curious about the role of fKeep data member in TClonesArray. > I recently realized that TClonesArray maintains 2 parallel arrays of > TObject*'s which it also tries to keep in sync - see > TClonesArray::operator[]. I'd expect that this procedure roughly doubles > the TObject* retrieval time and makes the bookkeping within the TClonesArray > kind of non-trivial. > > I guess that from educational point of view it would be pretty interesting > (and not only for me) to know what are the advantages of keeping a duplicate > array of TObject*'s - it is definitely not something lying on the surface. > > I'd appreciate any comments, thanks, Pasha. Hi Pasha, A fairly extensive description of the Root container classes is given in the Root courses part 2. See URLs: http://root.cern.ch/root/Publications.html and from this URL, see the Postscript file ftp://root.cern.ch/root/course2.ps.gs Look at pages 13 to 16. You will see pictures and comments explaining in particular the TObjArray, TClonesArray (fKeep and fCont). To be short, in the TClonesArray, fKeep points to an array of objects permanently allocated. fCont points to the current objects. Let me take an example. You create a TClonesArray of Track objects (as in $ROOTSYS/test/Event). You create this array only once (may be in a Run object). At the first event, you allocate, eg 650 tracks. fKeep will invoke 650 times the Track constructor. fCont will point to the fKeep objects. In your second event, you now have 720 Tracks. fKeep must be extended to 720. 70 new objects must be created. Both fKeep and fCont have a length 720. In your third event, you have only 450 Tracks. No new objects have to be allocated. fKeep has still a length of 720. fCont has only a length of 450. The main adavantage of TClonesArray is to save a FANTASTIC amount of time otherwise spent in the operators new and delete. Most of the time, we see people designing a class model working well for a reconstruction program because the time to reconstruct tracks exceeds the time spent in new/delete. But in the final data analysis phases, the situation may be totally different. If you are not careful, you may spend 99.9 per cent of your time in allocating and deallocating space!! We have found that the TClonesArray matches pretty well with many situations involving typical physics objects such as hits, digits, tracks, etc. when a large number of these objects must be created for each event. We have observed that non-Root users designing a class model comes to the conclusion that they cannot make objects for these low level physics objects because of the time problem in new/delete and also because the persistency model (say with Objectivity) adds also a huge overhead in disk space. Instead, they are forced to create arrays of basic types. This is a NICE STEP BACKWARD. The Root TClonesArray allows you to use a nice object model even for these low level types of physics objects. After all, that is what people see when doing physics analysis. You can use use the TClonesArray without a performance penalty. The TClonesArray solves also very elegantly the space problem on disk. There is ZERO overhead and even better, objects stored in a TClonesArray will occupy typically less space than if you store them by hand in conventional flat arrays because the Root compression algorithm will be very efficient on arrays of homogeneous data. The TClonesArray implies some restrictions when used with the split mode in TTrees. As reported several times to this list, objects in a TClonesArray must be CLONES with the same length when stored in a TTree. It could be that some additional classes (a la TClonesArray) could be added to cover some frequently encountered cases in event models. We are open to suggestions. Rene Brun The impossibility to
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:34 MET