Re: [ROOT] 2.25.03: TChain::Process + user defined TSelector sticks on first TFile and gets real slow

From: Matthew D. Langston (langston@SLAC.stanford.edu)
Date: Thu Sep 21 2000 - 21:08:36 MEST


Hi Rene,

I have verified that I am using ROOT 2.25.03.  I compiled ROOT 2.25.03
myself from the source tarball using gcc 2.95.2 under RedHat Linux 6.1
Intel.

The class that I sent you compiles (and runs) perfectly.  My "fTree" member
variable is of type "TTree*", which should be just fine.  You should be able
to compile it too - the C++ comment at the bottom of my attached source file
is how I compiled it.  What did you mean when you said that I should be
using the name "fChain" instead of the name "fTree"?  The name "fChain"
isn't even defined anywhere.

As I mentioned, I followed the example in the files h1analysis.h and
h1analysis.C in the tutorials subdirectory exactly.  The only difference is
that I am not using the fancier features that the h1analysis example uses
(i.e. I don't use TEventList, and I read all branches using
"fTree->GetEntry( entry );" instead of reading each TBranch individually).

Did you mean in your e-mail that I should change the type of my "fTree"
member variable to type "TChain*" instead of "TTree*"?  If so, how could
that possibly make a difference, since fTree is a pointer.  As a matter of
fact, the only interface that a TSelector provides for access to the
underlying TTree or TChain is via the TSelector::Begin member function:

virtual void Begin( TTree* tree );

Based on the design decision that went into making this interface, I would
argue that all user defined TSelectors should only depend on the TTree
interface and not the TChain interface.  Is this not correct?  Are you
suggesting that users be using "dynamic_cast< TChain* >( fTree )" and then
alter their behavior based on what the type of the underlying object the
TTree pointer (passed in via TSelector::Begin ) points to?  This just
doesn't seem right.

It really appears that there is a bug in TTree somewhere.  Unless someone
can point out a problem with the example TSelector that I attached, I can't
imagine any other conclusion.  Either I am using the TSelector interface
incorrectly, or there is a bug in the way TChain::Process  processes a
TSelector.

I would be happy to provide any other information to track down and solve
this problem.  Thank you for you help.

Regards, Matt

----- Original Message -----
From: "Rene Brun" <brun@pcbrun.cern.ch>
To: "Matthew D. Langston" <langston@SLAC.Stanford.EDU>
Cc: <roottalk@pcroot.cern.ch>
Sent: Thursday, September 21, 2000 6:16 AM
Subject: Re: [ROOT] 2.25.03: TChain::Process + user defined TSelector sticks
on first TFile and gets real slow


> Hi Matt,
> Are you really using 2.25/03? I do not understand how your piece of code
> can even compile. fTree should be fChain.
> Did you use the TTree::MakeSelector function to generate your skeleton
> class?
> I suggest you do. h1analysis.C works very well with 2.25/03.
> In the Begin function, look how the Init function initializes the branch
> address. Samething for the Notify function.
>
> Rene Brun
>
> On Wed, 20 Sep 2000, Matthew D. Langston wrote:
>
> > A call to TChain::Process on a user defined TSelector erroneously
> > iterates over and over again on the first TFile of a TChain.  In
> > addition, this second and subsequent erroneous iterations over the first
> > TFile is at least an order of magnitude slower than the first iteration,
> > if not more.
> >
> > I have attached the small, simple file named MySelector.cxx which
> > demonstrates this problem.  Notice that I defined MySelector::ProcessCut
> > as follows:
> >
> >   Bool_t ProcessCut( Int_t entry )
> >   {
> >      fTree->GetEntry( entry );
> >      return kTRUE;
> >   }
> >
> > Is this not the correct way to simply read in all of a TTree's
> > TBranches?  I also tried the following with the same result:
> >
> >   Bool_t ProcessCut( Int_t entry )
> >   {
> >      b_foo->GetEntry( entry );
> >      return kTRUE;
> >   }
> >
> >
> > I followed the example in the files h1analysis.h and h1analysis.C in the
> > tutorials subdirectory, which seem to do it as I describe as well.
> >
> > The nature of the problem suggests that the user is required to call
> > TChain::LoadTree during the call to TSelector::Notify, in a manner
> > similar to the case with the code generated by TTree::MakeClass.
> > However, it didn't seem like I should have to do this with a TSelector.
> > Could somebody help me please?  Thank you :-)
> >
> > Regards, Matt
> >
> > --
> > Matthew D. Langston
> > SLD, Stanford Linear Accelerator Center
> > langston@SLAC.Stanford.EDU
> >
>






This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:33 MET