Scott A Crosby wrote:
> 
> Also submitted under [BUG], cause I don't know about anyone else, but
> profiling is what made my fixes easy. And the normal profilier seems to
> error out and not report even large processes.
> 
> Try macrobenchmarks with and without this CS to see what I mean, its a
> hack, cause messagetally is confusing, but it helped me..

So are you trying "MessageTally spyOn: [Smalltalk macroBenchmarks]"?  I
get a MessageNotUnderstood if I try macroBenchmarks in a current
3.2alpha image. (bug report submitted in a different message)

Actually, running #macroBenchmarks covers so much stuff that I can see
why MessageTally might not be fine-grained enough.  But normally you'd
be better off testing one benchmark at a time anyway, so you don't need
that much detail.  I tried #macroBenchmark1 instead to try out your changeset.

Anyway, it is neat to see the detail down to 0.1% or so.  But I think
checking this often this starts to affect the results of the
MessageTally?  I haven't tested enough right now to confirm this, but I
thought this was the case...  at least the #macroBenchmarks1 message
tally took 51 seconds without your changeset, and 68 seconds with it.

Also, sometimes you don't want to see that much detail.  Maybe a
preference would be a good idea... fineGrainedMessageTally or something
like that.

> BTW, as a trade, can I ask a favor of someone who actually understands
> MessageTally, specifically 3 enhancements.
>   1. Some, maybe cleaner way of getting fine grained detail and not
> have it be thrown out, like I did in my changeset.
>   2. Some sort of cumulative mode, the more features below, the better.

There's also MessageTally class>>tallySends:, which does show all leaves
without leaving anything out, but it doesn't show time percentages, just
call counts. (be warned that this can generate huge lists... :) )

- Doug Way
  dway at riskmetrics.com