On Sun, 7 Oct 2001, Doug Way wrote:

> So are you trying "MessageTally spyOn: [Smalltalk macroBenchmarks]"?  I

Actually, I ran the benchmarks seperately.
>
> 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

Dunno.

> 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.
>

I agree, that much detail in the tree is annoying. But what I did was a
workaround for the real underlying flaw, that it doesn't notice methods
that have their time 'split up' between multiple invokers.

For example, use the stock messagetally, run macroBenchmark1, notice that
addLast: is consuming 23% of the CPU time. But, its not listed in the tree
at all! Hard to figure things out.

Ergo, my wishlist to have a cumulative mode for each method, showing the
method& its children, and the CPU taken by itself and those children,
accumulated over all of the invokers of that method. Also, a
who-invokes-who. Who invoked addLast; have it display all the invokers
that it knows about, and the percentage of the time addLast spent from
those invokers. (So you can follow 'addlast' up the invocation chain to
figure out whose at fault.)

Basically, something thats intermediate between the tree and the leaves.

BTW, if you look at my changeset, you should note that I have it query the
process every 1ms (the default is 16ms). Change that and it should behave
just as fast as the normal messageTally.


Scott



--
No DVD movie will ever enter the public domain, nor will any CD. The last CD
and the last DVD will have moldered away decades before they leave copyright.
This is not encouraging the creation of knowledge in the public domain.