> Is it true that the buffer size is not changeable when the tree is
> being accessed ?
The buffer size is only changeable while writing. Once the file is writing, this is not modifiable (this is a property of how the file is saved).
> Can that space occupied by data[100] be used as the buffer?
No. This is because the representation in memory is not necessarily the same as the representation on disk (big endian vs little endian).
> what is that (magic_overhead_size) ??? Is it a fixed number ? Or is
> it a function of some variables ?
It is not a fixed number. It depends on the branch. I think that in your case it is 64bytes.
Cheers,
Philippe.
-----Original Message-----
From: HP Wei [mailto:hp@rentec.com]
Sent: Monday, December 09, 2002 8:58 PM
To: Philippe Canal
Cc: roottalk@pcroot.cern.ch
Subject: RE: [ROOT] need info on low level stuff
> > The latter will be bad for speed concern if we only want
> > the first entry.
>
> It is later. It is assumed that in the most general case
>you would want to read the next event after that
>(reading 32K at in one
>disk read is more efficient that reading several time 800 bytes).
Thanks for this point. Now I understand why my test program in ROOT
is slower than an internal benchmark.
In our case, we need to read the 100 dimesion array
located in different part
of the branch. They are separated in a regular fashion, though.
I will try to reduce the buffer size to 1000!
----------------------------------
Is it true that the buffer size is not changable when the tree is
being accessed ?
When we generate the tree branch, can I set the branch's buffer size
to be 100*8 + (magic_overhead_size) ??
what is that (magic_overhead_size) ??? Is it a fixed nubmer ? Or is
it a function of some variables ?
How about this? When accessing, we usually set up an array data[100]
and SetBranchAddress("br", data). My question is:
Can that space occupied by data[100] be used as the buffer?
This way, the data will be there without the extra step of
moving from the buffer.
HP
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:23 MET