Re: [ROOT] Problems with TSelector

From: Rene Brun (
Date: Fri Jan 02 2004 - 09:50:39 MET

Hi Konstantin,

After our exchange of mails in December, I added the following comments
in the code generated by MakeSelector:

"Processing function. This function is called
       to process an event. It is the user's responsability to read
       the corresponding entry in memory (may be just a partial read).
       Once the entry is in memory one can apply a selection and if the
       event is selected histograms can be filled.
       WARNING when a selector is used with a TChain, you must use
       the pointer to the current Tree to call GetEntry(entry).
         entry is always the local entry number in the current tree.
         Assuming that fChain is the pointer to the TChain being 
         use fChain->GetTree()->GetEntry(entry)"

These comments were already in the code generated by MakeClass.

Processing a TChain should not introduce any performance penalty.
Please send a small concrete example showing the effect.

Rene Brun

Thu, 1 Jan 2004, Konstantin Olchanski wrote:

> On Fri, Dec 19, 2003 at 10:12:41AM +0100, Rene Brun wrote:
> > In the ProcessFill function, you should call GetEntry for
> > the current Tree in the chain, not for the chain itself.
> Wrong-----> fChain->GetEntry(entry);
> Correct---> fChain->GetTree()->GetEntry(entry);
> I confirm that the above fixes my problem with severe slowdown
> when processing chained trees (except for the very first tree).
> It is surprising that the two statements yeld the same results but
> have dramatically different performance.
> I suggest that this is at least a usability bug that should be corrected:
> - it is a mistake that is too easy to make (TTree->MakeSelector() no longer
>   adds the "correct" code to the class template),
> - it is hard to catch- the difference only shows up after the first tree,
>   and I only test the scripts on the first few hundred events of the first
>   tree,
> - it is a performance bug- the program yelds the correct answer, but takes
>   much longer to run, for no obvious reason.

This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:05 MET