Rene Brun wrote:
> Your difference in time has nothing to do with Streamer customization but with
> split/no-split. The automatic Streamers implemented in version 3.01
> will be as efficient as your trick and will be more portable. If you run
> with version 3.01 and have your shared lib containing your TCalTower class,
> simply do:
> gROOT->GetClass("TCalTower")->GetStreamerInfo()->ls();
> to see what the automatic Streamer will do on your class. In addition the
> automatic Streamer algorithm will check that the data members are really
> consecutive in memory. In your example, where you mix shorts with floats
> in the same class, you may have some surprises on some 64 bit machines (when
> working in 64 bit mode).
>
> In your example, you can play with the split level to split your TCaldataBlock
> class and not split the TClonesArray.
Hi Rene,
an 'old-style' autogenerated TCalTower::Streamer contains one '<<'/'<<' operator
per data member (short of float), each '<<' translated into a routine call. The call
itself takes more time than the [trivial] operations on streaming data members, so
in case of simple data members, the overall time consumed by this Streamer is
proportional to the number of those.
Apparently the Streamer I've written by hands is more efficient - one doesn't need
to do testing to see it, it is clear from looking at the code that the 'bare'
difference in performance between the hand-written and automatically generated
Streamers for the TCalTower class - I'm again talking about 'old-style' Streamers
- should be of the order of a factor of 4 - you have 2 routine calls instead of 9...
One more comment: I'm working with multibranch tree, where each top-level
branch stores a complicated object. For those branches, which are using
auto-generated Streamers I don't see any difference in performance between the
split and non-split modes (once again all this refers to ROOT 3.0 and older).
I will take a look at the automatic Streamers in 3.01 to see how more
efficient they are than the old ones and you're certainly right in that on 64-bit
architectures alignment in 64-bit mode may be different.
-best, Pasha
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:52 MET