[Help-smalltalk] Re: PATCH2/2: post processing and reporting

[Paolo Bonzini]

Derek Zhou wrote:
> On Friday 20 February 2009 05:55:09 am you wrote:
>> I settled for a single primitive, and I removed the global too.
> And the mystery of MethodDictionaty vs IdentityDictionary is solved too. Very 
> impressive.   
>> push/pop functionality is placed in a Profiler abstract class from which
>> I derived CallGraphProfiler and MethodCallGraphProfiler.  The two
>> classes should have the same purpose as the separateBlocks flag.
> Good.

Yeah, I plan to have more subclasses, for example Profiler->VMProfiler
(making push/pop abstract in the former).  I'd like to have simple
hierarchical timers for example, and they'd inherit from Profiler.

The CallGraphProfiler output could also be moved to a separate
ProfileTable class, so that a sampling profiler can reuse the callgrind
output code.  There's plenty of opportunities for refactoring but I did
only what was immediately useful.

> 1, inclusive cost calculation is not accurate. I think a "context sensitive"
> accounting is doable if we are willing to give up speed and space

Yes, that would probably work better with a sampling profiler.

> 2, the cost counter is SmallInteger so it overflows quickly.

There are facilities for 64-bit counters in the VM, but you have to be
careful not to allocate too many LargeIntegers

>> - check that the format is really the same as callgrind's, especially I
> There is a document at:
> http://valgrind.org/docs/manual/cl-format.html
> However it does not seems to match 100% what callgrind actually produce.
> I do know the profile produced by this is usable by kcachegrind

Yeah, it works well with callgrind_annotate too.

> Also I noticed you changed the "fl=" directive to source file name (like what 
> callgrind does) instead of class name. This is nice; I did not know gst 
> actually records file name and line number. Now that we do know the fine name 
> and line number we can change:
> positions: instr
> to:
> positions: line
> and change the "0" or "*" at the beginning or each cost line to the line 
> number of the method/block.

Good idea, yes (though not strictly urgent).

More short-term I'd like to make a gst-profile driver to make the
ProfilerTools package easy to use.  I guess that will expose the #fileIn
bug you mentioned, whatever it is...

Paolo