RE: [ROOT] TTree::Draw() performance depends on variable name abbreviation

From: Philippe Canal (pcanal@fnal.gov)
Date: Tue May 13 2003 - 17:21:25 MEST


> Since I'm lazy I tend to write the shortest possible query, but that
> gets penalized. I'm a little bit puzzled about this because the
> calculational realization of the query should not depend on such trivial
> changes of the input.

This is an expected consequence of the current implementation of the
short-cuts inside a TClonesArray.   Actually your usage of the short cuts
was not really anticipated :).  Let
me explain.

The code used to implement the short cuts was designed to allow the use of
variable name inside a non-split TClonesArray.  In this case, the variable
is refered to as an offset
inside the object and the full object is always read.

In your case you use the short-cut even-though the object has been split.
Nonetheless the
code being used is the one assuming that the object has nor been split and
hence it loads
the full object.  Thus the downgrade in performance!

TTreeFormula could be upgraded to double check whether the variable has
actually been split, however I am leaving for vacations for the next 3 weeks
so don't hold your breath :)

Cheers,
Philippe.


-----Original Message-----
From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Walter F.J. Mueller
Sent: Tuesday, May 13, 2003 8:54 AM
To: roottalk
Subject: [ROOT] TTree::Draw() performance depends on variable name
abbreviation


Dear ROOTers,            using 3.05/04/Linux/gcc 2.95.4

the CPU time needed to process a TTree::Draw() command can change by an
order of magnitude depending on whether the names are abbreviated or not.

In my example case I've a TTree with several branches, each branch is
split. The top level objects contains a TClonesArray, which in turn
holds objects with many scalar members. So a quite simple case.

In my first example I want to look at a scatter plot were two members
of the same branch are correlated, like pct.t.xs versus pct.t.xo, and
I try the commands:

   file = new
TFile("/d/kp3/tsm/s254/gen/run_mar03/ntu/qad/v1/qad_0740.root");

   tree->Draw("pct.t[].xs:pct.t[].xo")   // Cpu Time = 0.31 sec
   tree->Draw("pct.t.xs:pct.t.xo")       // Cpu Time = 0.31 sec
   tree->Draw("pct.t.xs:pct.xo")         // Cpu Time = 1.44 sec
   tree->Draw("pct.xs:pct.xo")           // Cpu Time = 2.12 sec

The CPU time was measured with TBenchmark like

   gBenchmark->Reset();
   gBenchmark->Start("scat_1");
   tree->Draw("pct.t[].xs:pct.t[].xo")
   gBenchmark->Show("scat_1");

The commands were repeated several times in a ROOT session, the results
are very reproducible and not distorted by other effect like caching etc.

The four command give exactly the same scatter plot, as they should.
But the CPU time seems to depend quite drastically on whether the
variable name is fully qualified or abbreviated. Each name with an
omitted middle name component causes obviously a penalty.

This penalty seems to even change when variables from two different
branches (and thus TClonesArrays) are correlated (rather than two
variables of the same branch).

In my TTree I have two branches, "pct." and "ict." which hold
different top level objects, both containing a TClonesArray, but with
different member class types. The number of array elements is equal for
all events, in fact the i'th element in each array holds just different
attributes of the same physical object. So queries combining members
of the two branches make perfect sense. I get the following timing

   tree->Draw("ict.t[].ampm:pct.t[].xo")   // Cpu Time = 0.33 sec
   tree->Draw("ict.t.ampm:pct.t.xo")       // Cpu Time = 0.33 sec
   tree->Draw("ict.t.ampm:pct.xo")         // Cpu Time = 1.60 sec
   tree->Draw("ict.ampm:pct.xo")           // Cpu Time = 3.20 sec

So the queries with fully qualified names have essentially the same
CPU time, but a query with two abbreviated names is significantly
slower as the same case with two variables from one branch (3.20 sec
versus 2.12 sec).

Since I'm lazy I tend to write the shortest possible query, but that
gets penalized. I'm a little bit puzzled about this because the
calculational realization of the query should not depend on such trivial
changes of the input.


	With best regards,

		  Walter


--
Walter F.J. Mueller   Mail:  W.F.J.Mueller@gsi.de
GSI,  Abteilung KP3   Phone: +49-6159-71-2766
D-64291 Darmstadt     FAX:   +49-6159-71-2989
WWW:   http://www-kp3.gsi.de/www/kp3/people/mueller.html



This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:11 MET