[squeak-dev] Can we make computing the local variables in the debugger lazy?

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Sep 19 18:57:09 UTC 2020


Hi Eliot,


very nice finding once again! I #timeProfile'd the menu button action and as I expected, the most expensive operation is the shout styling by the new inspectors, including the decompilation of every method:


[cid:1fdde244-d227-4d8d-9bfb-6b7176b7bc6f]

<http://www.hpi.de/>

First, when loading ShoutCore-ct.78 (Inbox), the speed doubles (but probably that's rather a problem with my sources file, see the thread about this commit).

Second, we do not redraw the world while running to the selection, so we do not need to update the inspectors at all. I think we could split up #doStep into some #basicDoStep (which would perform the actual stepping logic) + some #updateContextDuring: (which would update the stack list and the inspectors), then we would need to trigger the updates only once from #runToSelection:.
As an alternative, we could make this method a bit more complex but responsive by applying the same updating logic from #runUntil.

What do you think? :-)

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
Gesendet: Samstag, 19. September 2020 20:17:12
An: The general-purpose Squeak developers list; Taeumel, Marcel
Betreff: [squeak-dev] Can we make computing the local variables in the debugger lazy?

Hi Marcel,

    can we try and reduce the frequency at which we compute the variables in the context inspector in the debugger?  It is a noticeable performance hit.  I really like the user interface, but the performance hit is making debugging difficult.

As an example use this:

| samples sineTable sound |
"1 second of A below middle C (220Hz). 16000 / 220 is 72.72 recurring"
sineTable := SoundPlayer sineTable: 73.
sineTable doWithIndex: "And let's not deafen anyone..."
[:sample :index| sineTable at: index put: sample // 4].
samples := SoundBuffer new: 16000.
1 to: samples size by: sineTable size do:
[:i| samples replaceFrom: i to: (i + sineTable size - 1 min: 16000) with: sineTable startingAt: 1].
1 to: 146 do:
[:i|
samples at: i put: ((samples at: i) * i / 146) asInteger.
samples at: 16001 - i put: ((samples at: 16001 - i) * i / 146) asInteger].
sound := SampledSound
samples: samples
samplingRate: 16000.
sound := MixedSound new
add: sound pan: 0.25;
add: sound pan: 0.75;
yourself.
sound computeSamplesForSeconds: sound duration


Open a workspace in e.g. a 64-bit image prior to Tools-mt.965 (I used an image containing Tools-mt.942).  Debug the above in the workspace.  Position the cursor at "sound computeSamplesForSeconds: sound duration" and do "run to here".  It is essentially instantaneous.

Now do the same in a contemporary trunk image.  It takes almost 6 seconds.

I used to be able to click step as fast as I could and the system would keep up with me.  Now I find that if I click too fast I can accumulate excess clicks and when I stp clicking the system will continue stepping and go too far.

I don't want to lose the feedback the new variables list gives us.  But I do find the performance hit tedious.  I wonder could we cache the list and only update it
- when Morphic updates, and
- when the context changes?


_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200919/87a3017f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 399308 bytes
Desc: pastedImage.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200919/87a3017f/attachment-0001.png>


More information about the Squeak-dev mailing list