Hi Martin, The CINT optimization engine has many limitation. The one that you are actually reaching in the limitation on the size of a single function (i.e. more or the number of statement). The difference between 'filling 37 or 38 histograms) is this extra statement or two put you over the threshhold. When you reach the CINT optimization limits, I recommend switching to compile code (i.e. use ACLiC). Cheers, Philippe. -----Original Message----- From: owner-roottalk@pcroot.cern.ch [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Martin Turner Sent: Monday, April 15, 2002 2:04 PM To: roottalk@pcroot.cern.ch Subject: [ROOT] Re: Speed issues with filling histograms in TSelector If anyone is as intrigued about this speed issue as I am, I have some additional information. As explained before there appears to be a saturation point to the number of histograms I can fill in TSelector, but it also appears that the saturation is not just to do with histograms but also to get an entry from a branch. I'm going to include the TSelector.C script so that hopefully someone may spot something ugly. It should be pointed out that wether I have 38 histograms or 138 histograms it's still 15 times longer than it is if I have 37 histograms, wether they are filled or not! Martin On Sun, 14 Apr 2002, Martin Turner wrote: > Hello ROOT experts, I have a seemingly twisted speed related bug when > using TSelector. > TSelector is called using a pre-defined selection from TEventList. Before > begin is called, but inside the TSelector script, there are 22 histograms > made on the heap with names and range etc. and another 18 are made in > TSelector::Begin(). > It appears that my analysis macro takes a sweet 2 seconds to run provided > there are only 37 out of the 40 histograms filled. If there are 38 or > more, the job takes 32 seconds, which for a larger data sample makes my > script not very practical. This is the case even when I comment out > histograms that are not actually filled because they are dependent on a > particular flag in an if statement! Another related mystery is when I do a > cout<<.... in an if statement that is never passed, The time is takes for > my script to complete is comparable to the time it takes to complete if > the if statement does pass, yet I do not see the printout. Comment out the > cout statement and I'm back on 2 seconds. Has anyone got any idea what's > going on? I get the same problem running on two seperate computers with a > Linux and IRIS OS. > > Another problem is when I have an array of TStrings that contain the title > of histograms. I make a for loop to fill an array of histograms and attach > the associated title as I go. If the loop is at the top before > TSelector::Begin(); it crashes. If it's inside TSelector::Begin() it > works. Why should it matter? > > Thanks in advance > > Martin > >
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:50 MET