Hello Matt, Rene and Kalen,
Matt made a good point. Heap object does not disturb bytecode optimization.
It is a good tip to create heap object inside loop, rather than declare an
automatic object.
BTW, Rene,
I do not recall the change you mention here. Do you remember when it was
or which Cint version that was on?
Also, because I have only part of source code and may be data file is
needed, I can not run this program for debugging.
Thank you
Masaharu Goto
>Date: Wed, 23 Jan 2002 09:34:38 -0000
>From: "Matthew Palmer" <mjp39@cam.ac.uk>
>To: "Kalen Martens" <fmartens@physics.utoronto.ca>
>Cc: <roottalk@pcroot.cern.ch>, <cint@pcroot.cern.ch>
>Subject: Re: [CINT] Re: [ROOT] ROOT 20 times slower
>
>
>If speed is an issue then you should avoid creating objects on the stack.
>CInt compiles functions that are called more than once into bytecode which
>is significantly faster, but it can't do that if stack objects are created.
>I came across this issue recently and found a very significant speed
>improvement (10-20 times) by changing all objects to heap objects.
>eg in Rene's code use TVector3 *p_muon = new TVector3(); etc
>
>Check out: http://root.cern.ch/root/Cint.phtml?bytecode
>
>Matt
>
>> Your problem seems to be a consequence of the attempts by Masa to follow
>> the C++ scoping rules. I suggest that you change your very innefficient
>code
>> with the TVector3 declaration inside the inner loop as shown below.
>> In the previous versions of CINT, Masa was "optimizing" the code by
>calling
>> the TVector3 constructor only once. In the new version, he follows the
>> C++ scoping rules where the TVector3 object will be created and deleted at
>each
>> instance of the loop !
>> I am forwarding this mail to Masa for investigation.
>> Meanwhile, use this more efficient version of your code:
>>
>> TH1F *hmj = new TH1F("hmj", "muon-jet separation", 100, 0, 10);
>> Int_t nentries = h3333->GetEntries();
>> TVector3 p_muon;
>>
>> for (Int_t i=0; i<nentries;i++) {
>> h3333->GetEntry(i);
>> for (Int_t ii=0 ; ii<Npart ; ii++) {
>>
>> if ( TMath::Abs(Kfpar[ii]) == 13 ) {
>>
>> p_muon.SetXYZ(Pxpar[ii], Pypar[ii], Pzpar[ii]);
>>
>> for ( Int_t iii=0 ; iii<Njeta ; iii++) {
>>
>> Double_t rap_muon;
>>
>> rap_muon=p_muon.Eta();
>> hmj -> Fill(rap_muon);
>>
>> }
>> }
>> }
>> }
>>
>>
>> Rene Brun
>>
>>
>> Kalen Martens wrote:
>> >
>> > Hi Again,
>> >
>> > I've narrowed down the problem a little more.
>> >
>> > Yes, my PATH and LD_LIBRARY_PATH variables point to the new version. I
>> > never used the TTree::MakeCode in 3.02/07 to create my analysis code,
>but
>> > it does appear when I use it in 3.02/07.
>> >
>> > Below is the short bit of code from my h3333.C that generates a
>> > segmentation fault in 3.02/07 when it is first run. The interpreter
>> > recovers, and when it is run again, it takes a long time to go through
>the
>> > 50K events in the root file. The ROOT version 3.01/06 has no problem
>> > running this.
>> >
>> > (I loaded libPhysics.so at the beginning of the code.)
>> >
>> > // This is the loop skeleton
>> >
>> > TH1F *hmj = new TH1F("hmj", "muon-jet separation", 100, 0, 10);
>> >
>> > Int_t nentries = h3333->GetEntries();
>> >
>> > for (Int_t i=0; i<nentries;i++) {
>> > h3333->GetEntry(i);
>> > for (Int_t ii=0 ; ii<Npart ; ii++) {
>> >
>> > if ( TMath::Abs(Kfpar[ii]) == 13 ) {
>> >
>> > TVector3 p_muon(Pxpar[ii], Pypar[ii], Pzpar[ii]);
>> >
>> > for ( Int_t iii=0 ; iii<Njeta ; iii++) {
>> >
>> > Double_t rap_muon;
>> >
>> > rap_muon=p_muon.Eta();
>> > hmj -> Fill(rap_muon);
>> >
>> > }
>> > }
>> > }
>> > }
>> >
>> > I've just had a thought on this. Looking in TVector3.h, the constructor
>> > looks like:
>> >
>> > TVector3(Double_t x = 0.0, Double_t y = 0.0, Double_t z = 0.0);
>> >
>> > The variables Pxpar[ii], etc, are of type Float_t. Is this the problem?
>I
>> > can't find anywhere that tells me either that ROOT does an implicit
>> > conversion, or how to do a conversion explicitly between these data
>types,
>> > so I can't check it myself.
>> >
>> > Thanks,
>> > -Kalen
>> >
>> > On Tue, 22 Jan 2002, Rene Brun wrote:
>> >
>> > > Hi Kalen,
>> > >
>> > > I tried converting an old ATLFAST ntuple file into a ROOT file via
>h2root.
>> > > I generated the analysis code with TTree::MakeCode. 3.02/07 is
>slightly faster
>> > > than 3.01/06.
>> > > When you moved to 3.02/07, are you sure that you also changed your
>PATH
>> > > and LD_LIBRARY_PATH variables to point to the new version?
>> > >
>> > > When you execute TTree::MakeCode, you should have received the
>following
>> > > warning message:
>> > >
>> > > h3333.MakeCode("h3333.C")
>> > > Warning in <TTree::MakeCode>: MakeCode is obsolete. Use MakeClass or
>> > > MakeSelector instead
>> > >
>> > > Did you modify the generated code? Did you activate/deactivate some
>branches?
>> > >
>> > > Rene Brun
>> > >
>> > > Kalen Martens wrote:
>> > > >
>> > > > Dear ROOTers,
>> > > >
>> > > > I was using ROOT version 3.01/06 for some time. Using h2root, I
>converted
>> > > > a 50K event ntuple made with ATLFAST into a .root file. I used the
>> > > > TTree::MakeCode() method on the root file and created my script
>which
>> > > > took about 30 seconds to run with version 3.01/06.
>> > > >
>> > > > I downloaded and installed the binary version 3.02/07. That exact
>same
>> > > > script now took 10 minutes to run! Another side effect (related,
>perhaps)
>> > > > is that a segmentation fault occurs when I run this script for the
>first
>> > > > time after starting ROOT. The segmentation fault is non-fatal and
>the
>> > > > interpreter recovers.
>> > > >
>> > > > I can't figure out where the speed is lost and why the segmentation
>fault
>> > > > occurs. Maybe it's a backwards non-compatability? Any idea would be
>> > > > appreciated.
>> > > >
>> > > > I'm back using 3.01/06 for now.
>> > > >
>> > > > Thanks,
>> > > > -Kalen
>> > > >
>> > > > -----------------------------------------------------------------
>> > > > - Kalen Martens Ph:(416)-978-6632 -
>> > > > - Dept. of Physics -
>> > > > - University of Toronto, Toronto, Canada -
>> > > > -----------------------------------------------------------------
>> > >
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:39 MET