Christoph Borgmeier wrote: > > Dear all, > > I wonder, whether all of our philosophical problems have been discussed up > to an end. When I started to look into Root as an object-oriented > framework, I was a bit surprised, that all objects are kept in global > lists, and that there are globally current objects like pads, nodes, and > files. It seemed to me that this behaviour was directly inherited from > Root's Fortran predecessor and might conflict with oo-paradigms. After > working with it for some months, I got the impression, that these things > are well suited for interactive work. > > The C++ project, which I am involved in, was started a long time ago, and > we tried to do it the CLHEP/Ellemtel/STL way. For analyses, we agreed, > that the ZEBRA-bank style of event data storage is too static. It is > difficult, if not impossible, to insert or delete elements in the global > tables( i.e. no-constant indices for the entries). We did not want to > restrict ourselves to putting all instances of one class into the same > container. With some effort, we could use Root for interactive work (e.g. > all occurrences of templates had to be wrapped). > > This leads to a different system than the Root event examples Event/Track > and ATLFAST. Instead of TClonesArrays for each _type_ to be stored, we > wanted to create our own hierarchy of pointer-linked objects. The > possibility of handling such things seems to be a major advantage of > OODBs. When trying this with Root, we noticed another advantage: There are > many O(2000) particle tracks stored in the MC-events. In most cases, we > are only interested in the trigger particles, which are usually only two > and can be accessed by pointers. The reading of the trigger particles is > much faster than reading the entire container of tracks. > > My question now: Is this a valid model for use with Root and can the > problems described below solved with keeping this model? Since there are > other packages involved, this is a crucial question for us. > Hi Christoph, OK, I understand a bit better your problem now. A standard solution like the OODBs will not solve your problem in reality, because very likely your trigger particles objects are small objects. Due to page size considerations, you will not take advantage at all of the theoterical benefits of these systems (8K per page). I think that in your case, you should make a special container for your trigger particles. If you really deal with 2000 particles per event, you should "duplicate" your 1 or 2 trigger particles in a different container (TList or TObjArray or TClonesArray). The overhead in space will be totally negligible and you will have a huge performance gain. Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:30 MET