Re: was profiling broken in 110.63.1?

Joe Wells <[email protected]> Thu, 19 Nov 2009 15:29:01 +0000
Newsgroups gmane.comp.lang.sml.smlnj
Message-ID <[email protected]>
John Reppy <[email protected]> writes:

> Profiling occasionally gets broken; I'll look into it for 110.72.

So this is a bug and not a change in the interface?  If so, I'll file
a bug report.

> BTW, is there any reason that you are using 110.63, instead of the
> more recent versions?

I mentioned many versions in my e-mail: 110.54, 110.63, 110.63.1, and
110.70.

The test output I gave in my e-mail is from 110.54 (the version that
ships as part of Ubuntu Dapper Drake) and 110.70.  My PhD student
Vincent Rahli determined by trying many versions (in addition to those
I am mentioning) that the breakage seemed to be happening in the
change from 110.63 to 110.63.1 (2 and a half years ago).

I hope this clarification helps.

-- 
Joe

> 	- John
>
> On Nov 19, 2009, at 6:41 AM, Joe Wells wrote:
>
>> Dear SML/NJ gurus,
>> 
>> If I enter
>> 
>>  Backend.Profile.setProfMode true;
>>  let fun f 0 = () | f n = f (n - 1)
>>  in f 100;
>>     Backend.Profile.reportAll TextIO.stdOut
>>  end;
>> 
>> into SML/NJ 110.54, the profiling output I get looks like this:
>> 
>> %time cumsec #call  name
>>          .00   101  it.f.f
>>          .00     0  Compilation
>>          .00     0  Major GC
>>          .00     0  Minor GC
>>          .00     0  Other
>>          .00     0  Run-time System
>> 
>> I have not turned on timing mode, so the times are all zero, but the
>> count of the number of calls to f is correct.
>> 
>> In contrast, if I enter the same code in to SML/NJ 110.70, the
>> profiling output I get looks like this:
>> 
>> %time cumsec #call  name
>>          .00     0  Compilation
>>          .00     0  Major GC
>>          .00     0  Minor GC
>>          .00     0  Other
>>          .00     0  Run-time System
>> 
>> Notice that the profiler has not recorded any calls to the function f.
>> 
>> In fact, it seems that the table used by the profiler (as retrieved
>> using SMLofNJ.Internals.ProfControl.getTimeArray) does not change at
>> all when f is compiled in SML/NJ 110.70, whereas the table can be
>> observed to get bigger in 110.54.
>> 
>> My student Vincent Rahli has tried the profiler on many versions of
>> SML/NJ and he reports to me that the failures start in version
>> 110.63.1 (which was released two and half years ago).
>> 
>> Has there been a change in how the profiler is supposed to be used?
>> Is there some additional switch that needs to be adjusted
>> post-110.63.1 to turn on the instrumentation of compiled code with
>> profiling calls?  Or is this just a bug?
>> 
>> It would be really, really, really helpful if we did not have to
>> switch back to using 110.63 in order to get profiling.
>> 
>> Any help with this issue would be much appreciated!
>> 
>> -- 
>> Thanks,
>> 
>> Joe


-- 
Heriot-Watt University is a Scottish charity
registered under charity number SC000278.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july