Re: THnSparseF are oversized

From: Axel Naumann <Axel.Naumann_at_cern.ch>
Date: Tue, 24 Nov 2009 09:56:04 +0100


Hi Will,

I understand parts of it: THnSparse needs not only the count for each bin, but also its position. You have four dimensions, 32 bins in each, so that would be 4*5 bits = 2.5 bytes per bin, i.e. another 1MB. And then we have 4 axes plus all the statistics (fTSumw2 etc). Still - that should be much smaller.

Can you send me the file, please? And thanks for bringing this up, as I said: it does look weird.

Cheers, Axel.

Will Morrison wrote on 11/24/2009 12:50 AM:
> Hi rooters,
> My THnSparseF's seem to be oversized. For example, a 4D THn with 32
> bins in each dimension, and crr->GetNbins() = (const Long64_t)518332
> has a size on my hard drive of about 8MB. Shouldn't it be closer to
> 2MB, since sizeof(float)=4, 4 bytes*518332 = 2MB . Here is the Dump
> output, since I don't want to send something this large out over the
> list:
>
> Thanks!
> Will Morrison
> Boston University
> Statistical Physics Group
>
> crr->Dump()
> ==> Dumping object at: 0x0000000001af0860, name=hc, class=THnSparseT<TArrayF>
>
> fNdimensions 4 number of dimensions
> fChunkSize 16384 number of entries
> for each chunk
> fFilledBins 518332 number of filled bins
> fAxes ->1af08a0 axes of the histogram
> fAxes.*fCont ->1ae09b0 !Array contents
> fAxes.fLowerBound 0 Lower bound of the array
> fAxes.fLast 3 Last element in
> array containing an object
> fAxes.fSorted false true if collection
> has been sorted
> fAxes.fName ->1af08b0 name of the collection
> fAxes.fName.*fData
> fAxes.fSize 16 number of elements
> in collection
> fAxes.fUniqueID 0 object unique identifier
> fAxes.fBits 0x03004000 bit field status word
> fBinContent ->1af08d8 array of THnSparseArrayChunk
> fBinContent.*fCont ->1bcf030 !Array contents
> fBinContent.fLowerBound 0 Lower bound of the array
> fBinContent.fLast 31 Last element in
> array containing an object
> fBinContent.fSorted false true if collection
> has been sorted
> fBinContent.fName ->1af08e8 name of the collection
> fBinContent.fName.*fData
> fBinContent.fSize 32 number of elements
> in collection
> fBinContent.fUniqueID 0 object unique identifier
> fBinContent.fBits 0x03004000 bit field status word
> fBins ->1af0910 filled bins
> fBins.*fTable ->7f71bb912010
> fBins.fSize 889871
> fBins.fTally 518332
> fBins.fUniqueID 0 object unique identifier
> fBins.fBits 0x03000000 bit field status word
> fBinsContinued ->1af0930 filled bins for
> non-unique hashes, containing pairs of (bin index 0, bin index 1)
> fBinsContinued.*fTable ->1a94240
> fBinsContinued.fSize 101
> fBinsContinued.fTally 0
> fBinsContinued.fUniqueID 0 object unique identifier
> fBinsContinued.fBits 0x03000000 bit field status word
> fEntries 7.8804e+06 number of entries,
> spread over chunks
> fTsumw 7.8804e+06 total sum of weights
> fTsumw2 7.8804e+06 total sum of weights
> squared; -1 if no errors are calculated
> fTsumwx ->1af0968 total sum of
> weight*X for each dimension
> fTsumwx.*fArray 0 [fN] Array of fN doubles
> fTsumwx.fN 4 Number of array elements
> fTsumwx2 ->1af0980 total sum of
> weight*X*X for each dimension
> fTsumwx2.*fArray 9.20048e+07 [fN] Array of fN doubles
> fTsumwx2.fN 4 Number of array elements
> *fCompactCoord ->0 ! compact coordinate
> *fIntegral ->0 ! array with bin weight sums
> fIntegralStatus 0 ! status of integral
> fName ->1af0870 object identifier
> fName.*fData hc
> fTitle ->1af0880 object title
> fTitle.*fData hc
> fUniqueID 0 object unique identifier
> fBits 0x03000000 bit field status word
> root [10]
>
>
Received on Tue Nov 24 2009 - 09:54:03 CET

This archive was generated by hypermail 2.2.0 : Tue Nov 24 2009 - 11:50:03 CET