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