[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Derek Zhou
Subject: [Help-smalltalk] Re: PATCH2/2: post processing and reporting
Date: Fri, 20 Feb 2009 23:36:33 -0800
User-agent: KMail/1.9.9

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 
> 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.
> TODO (patches/testing are welcome):
The 2 biggest caveats are:
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
2, the cost counter is SmallInteger so it overflows quickly. To run the 
profiler for more than a couple of minutes we can make it 64 bit and somehow 
create a LargeInteger when passed back to the smalltalk world. 
Both of these are hard to fix, that's why I didn't do. :) 
> - comment and categorize methods
> - check that the format is really the same as callgrind's, especially I
There is a document at:
However it does not seems to match 100% what callgrind actually produce. I do 
know the profile produced by this is usable by kcachegrind, which seems to be 
the only possible consumer for the output file anyhow. 
> don't know if cumulative counts should be added to the caller as well?
From the document:
Note that regular cost lines always give self (also called exclusive) cost of 
code at a given position.
The 2nd line looks like a regular cost line with the difference that inclusive 
cost spent inside of the function call has to be specified.
So "regular" cost line (the ones defined by the original cachegrind) should be 
exclusive and the "association" cost line (the additional ones defined by 
callgrind) should be inclusive.  
> - find a way to remove the conditional from SET_THIS_METHOD???
one single conditional (and staticly predicted not taken) should be almost 
free. I timed a couple programs with and without it and cannot see any 
difference. There must be some thing to call the profiler hook and it does not 
get any faster than that. 
> Paolo
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
positions: line
and change the "0" or "*" at the beginning or each cost line to the line number 
of the method/block.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]