TObject::Write() differs from file size


I have a (stupid?) question. According to the manual TObject::Write() returns the number of bytes written to file.
In my case this is a tree which is the only object written to file.
But if I compare the number returned by TObject::Write() and the actual file size I find the file size to be much larger (by a factor of 10).
Why is this?

A ROOT file consists of
-a file header
-a directory info
-list of objects
-meta data (StreamerInfo) of objects wriiten to the file
-a file trailer

Use myfile.Map() to see the layout and number of bytes occupied by each section or/and object.


Okay, I tried that and I see that there are loads of TBaskets in the file and only one TTree (with the size reported by TObject::Write). So are those baskets from the autosave? And is TObject::Write just reporting what was written to the file in that last step which means is this case just the keys of the tree?
How can I find out how big the tree is that was written to file?

You get this information when calling TTree::Print(whole tree and branch by branch).
You can also call tree.GetZipBytes() to get the total zip data in the branch baskets.


[quote]So are those baskets from the autosave?[/quote]No. For each split branch there is a basket (32K by default) in memory. At each Fill, the various piece of your event data is accumulated in all the baskets. One a basket is full (so after several thousands events if the branch contains with a double), the basket is written to disk. So the each ‘basket’ on the disk is a portion of the data for one of the branch[quote]And is TObject::Write just reporting what was written to the file in that last step which means is this case just the keys of the tree? [/quote]Yes.


Thanks for the help!

TTree::GetZipBytes() works great. Now I have one other question.
I’m trying to reduce the file-size of a root-file with just one tree in it. The tree has only one branch which is a class I wrote and which contains vectors of different other classes.
I’ve found out that increasing the basket size of the branch decreases the size of the tree as well as the size of the file. But at some point this is not the case anymore and while the tree size is still getting smaller the file size is actually increasing:
Basketsize: 1024000 => tree = 20822954 bytes, file = 23M
Basketsize: 10240000 => tree = 15601459 bytes, file = 25M

Is this due to some overhead? And is there any rule what the optimal size for the basket is if the file is supposed to be as small as possible?

When increasing the basket size, you improve the compression factor and reduce the table of baskets. In your case, the gain is likely coming from the improved compression.
See another example where the number of baskets was a potential problem (
Note that in general, it is not a good idea to have a Tree with a single branch. By splitting your Tree into more branches, you will improve the compression factor (typycally by 20 to 30%).
Also note that making large baskets is good when you process all your entries, but not good at all if you want to read (say 1% of your events) and you have 1000 events per basket.