From serban@bnl.gov Mon May 10 20:02:22 2004 Date: Sat, 08 May 2004 10:51:20 -0400 From: "Protopopescu, Serban D" To: 'Laurent Duflot ' , "'owner-d0dfwg@listserv.fnal.gov '" , 'Herbert Greenlee ' Cc: 'D0 Data Format Working Group ' Subject: RE: Tmb+ size analysis [ The following text is in the "iso-8859-1" character set. ] [ Your display is set for the "US-ASCII" character set. ] [ Some characters may be displayed incorrectly. ] Hi, Some bloating of EMparticle comes from storing all em cells associated with it. This is not done in a very efficient way as most cells are stored twice (once for scone algorithm and separately for nn algorithm). In the tmb tree we save some space by storing any cell only once and keeping instead a TRef in each TMBEmcl. Also, I think you will find that after compressing the em information is no larger than the charged particle information. Serban -----Original Message----- From: owner-d0dfwg@listserv.fnal.gov To: Herbert Greenlee Cc: D0 Data Format Working Group Sent: 5/7/2004 8:21 PM Subject: Re: Tmb+ size analysis On Fri, 7 May 2004, Herbert Greenlee wrote: > Hello, > > Attached find an analysis of tmb+ size by chunk and tmb object. > > By chunk, most size is consumed by three large chunks: ThumbNailChunk > (45%), L1L2Chunk (34%), and CalDataChunk (18%). > > Space in ThumbNailChunk is being dominated by three large objects: em > particles (46% of ThumbNailChunk), charged particles (16%), and L3 (12%). > > I found the amount of space for em particles surprising. The large space > is attributable in part to the fact that each em particle object weighs in > at a bloated 850 bytes (average, packed, uncompressed). I assume that > most of em particle doesn't make it to the tmb_tree, but I don't know for > sure. Browsing shows that a high fraction of em particle data is zero. I suspect that the criteria to define an EM candidate are very loose and that we could gain by applying a tighter hmatrix cut. If I remember well EMparticle has the cells information in a fixed-size grid around the cluster center (or leadin cell) that could have a lot of zeros and there are also candidates (road electrons?) for which that does not mean much. Overall I suspect that in many areas in the D0 code, we would benefit from having code reviews. Laurent > > Regarding charged particles, I confirm Suyong's figure of 44 bytes > (packed, uncompressed) in the p14 thumbnail. The size of charged > particles in the tmb++ will go up a lot (like maybe a factor of three) due > to inclusion of cluster indices. > > Herb >