Re: again ROOT db (long) (fwd)

Christoph Borgmeier (borg@mail.desy.de)
Thu, 2 Apr 1998 13:15:46 +0200 (MST)


sorry, if this appears twice somewhere. It is a reply on a Rene Brun mail.

---------- Forwarded message ----------
Date: Wed, 1 Apr 1998 14:51:29 +0200
From: Christoph Borgmeier <borg@hera-b.desy.de>
Newsgroups: cern.root
Subject: Re: again ROOT db (long)

Hi Rene,

thank you for the detailed answer. I understand now a lot more than
before, esp. about the fact, that there cannot be cross-links between two
branches.

I have also tried the feature of avoiding multiple versions of the same
object in a file. But I still ran into the problem of memory leaks. The
additional objects are neither reused nor deleted when reading the next
event. The effect might be neglectable in case of TCanvases, but in my
event example I get ~80MB of memory leaks when reading an event sample.
That means, although everything else is working fine, I have to restart
ROOT every time I want to restart my loop macro.

As mentioned in my previous posting, I tried already to build my own
garbage collection but failed so far. Could the ROOT garbage collection
classes be of any use?

Christoph

On 31 Mar 1998, Rene Brun wrote:

[...]
> The best of the two worlds
> ==========================
> A good object model is clearly the best compromise between a coherent
> object model preserving the internal object structure and the
> requirements
> to access subsets of an object graph/tree.
> To take the example of an Event class, a good structure should look
> like:
> - object header
> - some pointers to objects graphs (will be serialized)
> - As many pointers to TClonesArray as possible.
>
> Ideally, one should be able to automatically split the Event class
> into branches (case of $ROOTSYS/test/Event example). This example
> combines the two modes. We also provide a different example (ATLFast)
> where branches are built by the application.
> It could be that some special classes must be added to the system to
> cover more general cases. We will be happy to add such classes to Root
> if they appear to be of general interest.
[...]