I've made some progress with the Chain problem - I was using the local
Tree entry number where I should have been using the global chain entry
number and since doing that, the chain problem has gone away. As a result
I may now be able to shed some more light on the strange I/O speed
problem.
Part of the code can act as an event filter and in this mode it fills a
TEventList and then using this is attempts to make a copy of the tree. My
initial attempts at this failed because I did not set the branch address
for each branch (is there anyway to copy a tree without setting the branch
address for all branches?). So I backed off to the slower code where only
the branch I want is enabled.
However the code still crashed when I attempted to close the file
containing the cloned tree. Dropping the file close from the code I was
then able to look at the still open file in the browser. Instead of seeing
a copy of the tree with only the 'Muon' branch from the original (which
should be the only branch turned on) I saw a subset of branches. The Muon
branch was correctly copied but the other branches also made it across
from the original tree despite being turned off.
I've attached the results of the print of the new tree formed. As you can
see some elements of several other branches have been copied but have
somehow mutated from their original form in the process since they now
appear as arrays rather than member variables of an object.
The code used to write the new tree is:
void OutputFilter::doDone(void) {
// function called at the end of the event loop
// Only open a new output file if there are any entries
if(_list.GetN()) {
tree()->SetEventList(&_list); // Set the event list to use
// Open the output file
TFile *tmpfile = new TFile(_outfile.c_str(),"recreate");
// Copy the tree using the event list
TTree *newtree = tree()->CopyTree("");
tree()->SetEventList(0); // Remove the event list
newtree->Write();
tmpfile->Close();
_list.Reset(); // Reset the event list
} else {
cout << "No events to write to file " << _outfile << endl;
}
}
where _list is a TEventList member of the class and tree() returns a
pointer to the input tree/chain in use. With only the Muon.* branches
enabled the code runs but crashes at the 'tmpfile->Close();' command.
Hope this helps,
Roger
On Fri, 27 Sep 2002, Rene Brun wrote:
> Hi Roger,
>
> Could you move to version 3.03/09 and tell me if this symptom persists?
> If it does, please send me the result of
> tree.Print();
> for your old and new Trees
>
> Rene Brun
>
> On Fri, 27 Sep 2002, Roger Moore wrote:
>
> > Converting some analysis code from using a ROOT-tuple to using a ROOT Tree
> > (i.e. from individual variables in arrays to real objects) I've noted some
> > very strange behaviour with the readout speed.
> >
> > With the old ROOT-tuple I could vastly increase the speed of the code by
> > turning off all branches and then just turning back on the branches that I
> > was interested in looking at.
> >
> > However with the shift to the ROOT-Tree whose branches consist of
> > TClonesArray the exact reverse is true! When I turn off all the branches
> > except the one I am interested in the GetEntry() method of the tree takes
> > 50-60ms to execute. However when I to not turn the branches off the time
> > taken for GetEntry() drops to ~3ms/event.
> >
> > Does anyone understand what is going on here? I don't see how not
> > unpacking a branch can possibly slow the code down!
> >
> > I'm using ROOT 3.03/07 and in both cases I only do SetBranchAddress (to a
> > TClonesArray) for the branches I am interested in reading out.
> >
> > Roger
> >
>
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:12 MET