[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
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.
>
> 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:
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, 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
to:
positions: line
and change the "0" or "*" at the beginning or each cost line to the line number
of the method/block.
Derek