I write TTrees with variable length arrays of both UShort_t’s and UChar_t’s. For a given entry, there are the same number of each. Here’s an excerpt from TTree::Print():*............................................................................*
*Br 1 :x0 : x0[nx0]/s *
*Entries : 346326 : Total Size= 2170685 bytes File Size = 1216236 *
*Baskets : 110 : Basket Size= 32000 bytes Compression= 1.77 *
*............................................................................*
*Br 2 :x0b : x0b[nx0]/b *
*Entries : 346326 : Total Size= 1800669 bytes File Size = 566627 *
*Baskets : 98 : Basket Size= 32000 bytes Compression= 3.11 *
*............................................................................*
*Br 3 :x1 : x1[nx1]/s *
*Entries : 346326 : Total Size= 2160175 bytes File Size = 1204426 *
*Baskets : 110 : Basket Size= 32000 bytes Compression= 1.78 *
*............................................................................*
*Br 4 :x1b : x1b[nx1]/b *
*Entries : 346326 : Total Size= 1795395 bytes File Size = 565978 *
*Baskets : 98 : Basket Size= 32000 bytes Compression= 3.11 *
*............................................................................*My questions are: why is “Total Size” entries odd? - I assumed that this is the uncompressed size. Also, why is the “Total Size” of the UChar_t array so close to the corresponding size of the UShort_t? (x0 and x0b have same number of elements, x1 and x1b have same number of elements).
I assume that “File Size” means size after compression - this does make sence - the UChar_t’s are roughly have as the UShort_t’s.
I am using root release 5.06/00 on windows XP. I write the TTree with default compression size (1) Thanks!
Ed
Ed,
Easy to explain. When you use variable size arrays, we have to store
the array length as an integer. In case of very small arrays (your case)
this overhead may not be negligible. Of course the compression takes care.
Rene