Hi Marcel, Hi All,

    I finally got round to identifying the bottle neck, and it is a deep recursion within nanosecondsToRunHighRes:.  Here's the profile for doing a "run to here..." in the debugger on a not too complex class (TMethod). And I should say that this is using a trunk Squeak 6 derived, fully updated VMMaker image on a tip Cog VM on MacOS Monterey 12.7.4 on a 16" 2021 MacBook Pro w 64Gb.

[                                                                |54.6% {11716ms} Debugger>>contextStackIndex:oldContextWas:
[                                                                |  54.6% {11712ms} Debugger>>restoreReceiverInspectorState
[                                                                |    54.6% {11712ms} WeakIdentityKeyDictionary(WeakKeyDictionary)>>at:ifPresent:
[                                                                |      54.6% {11712ms} WeakIdentityKeyDictionary(Dictionary)>>at:ifPresent:
[                                                                |        54.6% {11712ms} [] Debugger>>restoreReceiverInspectorState
[                                                                |          54.6% {11712ms} Inspector>>selectFieldNamed:
[                                                                |            54.6% {11712ms} Inspector>>selectFieldSuchThat:
[                                                                |              54.6% {11712ms} Inspector>>selectionIndex:
[                                                                |                54.6% {11712ms} Inspector>>updateContentsSafely
[                                                                |                  54.6% {11709ms} FullBlockClosure(BlockClosure)>>ifError:
[                                                                |                    54.6% {11709ms} FullBlockClosure(BlockClosure)>>on:do:
[                                                                |                      54.6% {11709ms} [] Inspector>>updateContentsSafely
[                                                                |                        54.6% {11709ms} Inspector>>getContents
[                                                                |                          54.6% {11709ms} FullBlockClosure(BlockClosure)>>timeToRun
[                                                                |                            54.6% {11709ms} Time class>>millisecondsToRun:
[                                                                |                              54.6% {11709ms} Time class>>microsecondsToRun:
[                                                                |                                54.6% {11709ms} Time class>>nanosecondsToRunHighRes:
[                                                                |                                  53.8% {11535ms} Time class>>nanosecondsToRunHighRes:
...
[[[                                                                                                                    1.3% {287ms} Time class>>nanosecondsToRunHighRes:
[[[                                                                                                                      1.2% {263ms} Time class>>nanosecondsToRunHighRes:
[[[                                                                                                                        1.1% {245ms} Time class>>nanosecondsToRunHighRes:
[[[                                                                                                                          1.1% {226ms} Time class>>nanosecondsToRunHighRes:
[[[                                                                                                                            1.0% {216ms} Time class>>nanosecondsToRunHighRes:

On Mon, Feb 26, 2024 at 4:26 PM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Hi Eliot,

have you already found a bottleneck? :-)

Can you record a trace (using the profiler from the main docking bar > extras menu) while stepping around in the debugger for about 10 seconds and share it with us? Yes! Cool! I didn’t know this existed. Silly me!! Thanks!!
By the way, I had made an attempt to document all profiling tools in the image in section 6.7 ("Other interesting tools") of the Squeak by Example book (ed. 6.0).
https://github.com/hpi-swa-lab/SqueakByExample-english/releases/download/6.0/SBE-6.0.pdf#section.6.7
If I have missed anything, please educate me!

Best,
Christoph
Von: Eliot Miranda <eliot.miranda@gmail.com>
Gesendet: Donnerstag, 15. Februar 2024 21:00 Uhr
An: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Betreff: [squeak-dev] Re: trunk debugger unusably slow...
 
Hi Christoph,


On Feb 12, 2024, at 5:38 PM, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:


Hi Eliot,

Does the issue resolve when you turn off the preference syntaxHighlightingAsYouType?

I’ll check but I do t think so. What slows things down is having fields selected in the context and receiver inspectors.

Can you record a trace (using the profiler from the main docking bar > extras menu) while stepping around in the debugger for about 10 seconds and share it with us?

Yes! Cool! I didn’t know this existed. Silly me!! Thanks!!


Best,
Christoph
Von: Eliot Miranda <eliot.miranda@gmail.com>
Gesendet: Dienstag, 13. Februar 2024 02:32 Uhr
An: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>
Betreff: [squeak-dev] trunk debugger unusably slow...
 
Hi All,

    I'm trying to debug an inlining edge case in the VM for the threaded VM that Leon is doing. The debugger is unusably slow (steps taking 10 seconds, etc).  I've raised this issue before but was brushed off.  I suspect somewhere in the new (last two years?) highlighting code is taking a lot of time.  Would the author(s) please provide me with some snippets of code i can use to try and measure performance? And/or would anybody be willing to pair (I'm on PST) in trying to get to the bottom of this?  It's extremely frustrating to try and work when the debugger is unusable.

_,,,^..^,,,_
best, Eliot




--
_,,,^..^,,,_
best, Eliot