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

From: Rene Brun (Rene.Brun@cern.ch)
Date: Mon Oct 02 2000 - 13:12:58 MEST


Hi Matt,
The ProcessCut and ProcessFill function have one argument "entry" that is
the entry number in the current Tree (not the entry number in the TChain).
This important point was not clear in the 2.25/03 documentation.
I have added comments at the relevant places where these functions are
described and also added comments in the code generated by TTree::MakeSelector.
In your case fTree (called fChain ij the automatically generated code)
points to the TChain object. you should replace your statement:
         fTree->GetEntry( entry );
by
         fTree->GetTree()->GetEntry( entry );

where fTree->GetTree() points to the current TTree. Better rename your fTree
to fChain as I told you in a previous mail.

In the case of h1analysis.C example in tutorials, the code is correct
because we call only TBranch::GetEntry that in turns correctly calls GetEntry
for the current Tree.

Rene Brun


Matthew D. Langston wrote:
> 
> 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
> > >
> >
> 
>   --------------------------------------------------------------------------------
> 
>                         Name: MySelector.cxx
>    MySelector.cxx       Type: unspecified type (application/octet-stream)
>                     Encoding: BASE64
> 
>                           Name: root_version.txt
>    root_version.txt       Type: Plain Text (text/plain)
>                       Encoding: 7BIT



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