[3] [gclist] GC & profiling

[eliot@parcplace.com]

-covering message-

+-----------------------------
| Date:	Tue, 24 Apr 2001 04:13:26 +1000
| From:	Fergus Henderson <fjh@cs.mu.oz.au>
| Subject:	Re: [2] [gclist] GC & profiling

| On 23-Apr-2001, eliot@parcplace.com <eliot@parcplace.com> wrote:
| > Fergus Henderson <fjh@cs.mu.oz.au>:
[snip]
| > | Do you mean that
| > | 	- if a profiling timer tick occurs during GC, that tick is discarded?
| > | 	- if a profiling timer tick occurs during GC, that tick is credited to
| > | 	  the currently active Smalltalk method?
| > | 	  (This is what happens in the current Mercury profiler.)
| > | 	- profiling ticks can never occur during GC (e.g. because the
| > | 	  profiler actually counts number of bytecode instructions executed,
| > | 	  rather than time)?
| > | 	- something else?
| >
| > Option 2,  if a profiling timer tick occurs during GC, that tick is
credited
| > to the currently active Smalltalk method, which means GC costs are
effectively
| > hidden.

| OK, so it sounds like you're doing the same kind of thing as in the current
| Mercury profiler, with the same potential for misleading results.

| It's nice to know from Nick Barnes' post that the Harlequin MLWorks
| profiler got this right.  But since Harlequin went out of business,
| I'm not sure what that tells us :-(  Perhaps the only thing to be learnt
| from this is another one of those depressing worse-is-better lessons:
| maybe the problem is just not sufficiently important in practice to
| be worth worrying about.

:)  I wouldn't put that spin on it.  Instead I'd say that resources are
limited and given our profiler provides useful, if imperfect information, it
is currently good enough, with work on other areas taking priority.  For
virtual machine tuning I use a much lower-level profiler, a PC histogram built
either above profil(2) on Unix or custom thread machinery (Windows).  I use
Smalltalk to select/display the data, with some level of integration into the
profiling framework, so you can get the vm profiler to profile a lamda, via
e.g.
	OEProfiler profile: [MyBenchmark run]
just as you can say
	TimeProfiler profile: [MyBenchmark run]

But this kind of profiling info is typically too low level for most
developers.  Given that the programmer has control over algorithm and hence
allocation, presenting execution costs and allocation rates is at least
presenting them with relevant information.  Being picky about exact cost
centers for distinctions that are important only to implementors isn't going
to help the developers much if they have little or no control over the
distinction being presented.  Much more important, in my experience, is good
developer-oriented documentation of the gc system, and then trying to get
developers to read it :)

| --
| Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the
pursuit
|                                     |  of excellence is a lethal habit"
| WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
---
Eliot Miranda                ,,,^..^,,,
mailto:eliot@parcplace.com
VisualWorks Engineering, Cincom    Smalltalk: scene not herd Tel +1 408 216
4581
3350 Scott Boulevard, Building 36, Santa Clara, CA 95054 USA Fax +1 408 216
4500