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 _______________________________________________ help-smalltalk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
