Re: MakeClass

Rene Brun (Rene.Brun@cern.ch)
Mon, 19 Apr 1999 21:45:41 +0200 (METDST)

Hi Jacek,
Since you are pushing me for more info on my proposed algorithm,
here it is:
I propose to make an absolutely trivial mod to TTree::MakeClass,
add a statement like:
tree->SearchActiveBranches("file.C");
where file.C is the file containing the main loop generated
by MakeClass.
SearchActiveBranches will read the ascii file file.C scanning
all lines and searching for references to the Tree variable names.
For each referenced variable, I will automatically call
tree->SetBranchStatus. That's all !!
You can imagine (and I trust you to propose additions/substractions)
a more elaborated mechanism to take into account the case where
the analysis code is spread over several files.
Note that this algorithm will immediatly work in case the macro
is compiled thanks to the new algorithm currently being developped
by Philippe.
My guess is that this algorithm will be more performant than you algorithm
in most cases.
One could also imagine to combine this algorithm with your proposed
algorithm to take into account variables used only conditionally.

Rene Brun

On Mon, 19 Apr 1999, Jacek M. Holeczek wrote:

> Hi,
> Thanks for your reply.
> > However, there are several problems with your implementation:
> > - It is only valid for trivial TNtuples.
> > - a branch cannot be an array (even static).
> > - a branch cannot be an object.
> As I have already written :
> > > For the time being the MakeClass.cxx macro is quite dumb.
> > > Feel free to add something to it ... .
> Well, I hoped you could have a look at it and add something ... . :-)
> Anyhow, I have just sent a modified MakeClass.cxx macro which might work
> ( or not ) for other cases, too.
> > - reading the code is made more difficult.
> For me, not really - 'leaf()' is not so much different from 'leaf'.
> > - you introduce a performance penalty.
> How much ? A call of a function against an access of a variable ?
> As I have already written :
> > > ( Of course, I know - calling a function is always slower then accessing
> > > directly a variable, but ... if I subtract the time spent to find missing
> > > SetBranchStatus and the time spent to load unneeded branches ... .)
> I should also add here, that the decision to "load" ( or not ) a branch,
> happens on an event by event basis. One "loads" only these branches that
> are currently required.
> If one uses a specific "leaf" many times in ones routine, it's just enough
> to write 'register int leafleaf; leafleaf=leaf(); ...', and then one can
> use the 'leafleaf' as many times as one wants in the routine. The
> "performance penalty" of calling a function ( once ) is negligible.
> > I have in mind an automatic algorithm similar to the one we implemented
> > ( ... )
> This might be nice.
> But, do you mean that every leaf name that the algorithm finds will be
> added into SetBranchStatus ? Will you "detect" leaves that will never be
> accessed ? Or will you detect that for a particular event(s) some leaves
> are not accessed, while some others do ? Or how do you want to deal with
> cases where leaf names are "computed" on the fly ( these are just simple
> C strings, you can do everything with them )?
> And then comes the question - possibly it might be working from inside of
> the clever interpreter, but what happens if one want to create the shared
> library ? No smart "automatic macro compilation" will be called then.
> Jacek.
>