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
processed,
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
On
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