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).
[ |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... 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 threadedVM 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