Hi Rene,
> Could you send me evidence that using the option "+" introduces a factor two
> penalty in I/O ?
right now it is not easy to repeat. But as I told, this result was for very complicated
structure (STAR StEvent) with a lot of inheritance and class members.
> What we have seen in many applications is typically 5 to 15 per cent.
I think for more simple cases your result is also correct.
In additoion I did compare with my STAR-schema evolution and result was the
same. I mean my compiled STAR schema evolution has the same slowdown as yours.
Probably it is unavoidable penalty for complexity of the classes.
> The new system may even be faster than the old one if you have a good
> class layout. I see so many cases where people mix ints with floats, doubles,
> etc !
StEvent has a lot of class in class in class etc. So it could not be aligned easily.
It is of course the additional factor of the slowdown
Anyway, schema evolution is so important that it is better to lose cpu time
than the human time.
Victor
Rene Brun wrote:
>
> Hi Victor,
>
> Could you send me evidence that using the option "+" introduces a factor two
> penalty in I/O ? What we have seen in many applications is typically 5 to 15
> per cent. The new system may even be faster than the old one if you have a good
> class layout. I see so many cases where people mix ints with floats, doubles,
> etc !
>
> Rene Brun
>
> Victor Perevoztchikov wrote:
> >
> > Hi Thomas,
> >
> > > > I'm writing data like in the following example (using root 3.01/06, with
> > > > a '+' in the pragma statement for MyClass):
> >
> > when you use a '+' you use not compiled code for the Streamer.
> > By my tests, for complicated classes, it is about twice as slower then compiled one.
> >
> > But "+" provides you an automatic schema evolution.
> > If you very aware about the speed and not worry about schema evolution at all,
> > you should not use "+". But then , if you will deside to change your class
> > you will have a lot of problems.
> >
> > This slowdown is a payment for the schema evolution. You should choose
> > what is more important for your application.
> > But I must say, that often user supposes that his application is temporary,
> > but at the end it is used years and years.
> >
> > Victor
> >
> > Rene Brun wrote:
> > >
> > > Hi Thomas,
> > >
> > > Difficult to come with a dignostic without looking into your system.
> > > I have no idea of what you mean by "rather slow".
> > > >From your class description, I conclude that you have about 20 Kbytes per event.
> > > One million entries will make a file of about 20 GBytes.
> > > Could you send me:
> > > - the result of tree.Print() after filling your Tree.
> > > - if possible your class with a small test that is slow.
> > >
> > > Rene Brun
> > >
> > > Thomas Bretz wrote:
> > > >
> > > > Hello rooters,
> > > >
> > > > I'm writing data like in the following example (using root 3.01/06, with
> > > > a '+' in the pragma statement for MyClass):
> > > >
> > > > {
> > > > MyClass *cls = new MyClass;
> > > >
> > > > TFile file("name", "RECREATE", "title", 0);
> > > > TTree tree("name, "title");
> > > > tree.Branch("MyClass", "MyClass", &cls, 320000, 0);
> > > >
> > > > for (int i=0; i<1e6; i++)
> > > > {
> > > > FillDataIntoMyClass(&cls);
> > > > tree.Fill();
> > > > }
> > > > file.Write();
> > > > delete cls;
> > > > }
> > > >
> > > > Because this is rather slow, I used gprof to find out where the time is
> > > > spend and if I trust its output, only ~15% of all the time (CPU time,
> > > > which should not include I/O) is spend in my part of the program. This
> > > > means about 85% of the CPU-time is spent in root (I/O). In this example
> > > > speed is really critical. Is there a way to accelerate the root output?
> > > >
> > > > I don't think that it is a question of hardware limitation because the
> > > > machine and disks are really powerfull.
> > > >
> > > > Rem: MyClass contains four arrays. Two about 1kB, and two around 8kB.
> > > > (around 18kB in total)
> > > >
> > > > Thanks in advance,
> > > > Thomas.
> >
> > --
> > Victor M. Perevoztchikov perev@bnl.gov perev@vxcern.cern.ch
> > Brookhaven National Laboratory MS 510A PO Box 5000 Upton NY 11973-5000
> > tel office : 631-344-7894; fax 631-344-4206; home 631-345-2690
--
Victor M. Perevoztchikov perev@bnl.gov perev@vxcern.cern.ch
Brookhaven National Laboratory MS 510A PO Box 5000 Upton NY 11973-5000
tel office : 631-344-7894; fax 631-344-4206; home 631-345-2690
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:05 MET