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. [...]
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:31 MET