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
Hi Eliot,
Does the issue resolve when you turn off the preference syntaxHighlightingAsYouType? 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?
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
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
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 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
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
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... 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
i would like a debugger GUI which is tabbed i think
some tabs would have single panes like one stack pane or one variables pane or one source pane
and other tabs would have 2 panes in them like stack + variables
stack + source with the panes as columns with the stack on the left
or stack + source with the panes laid out as rows with the stack on top
or 3 panes like stack + variables + workspace in various layouts
and a tab that has the standard squeak Debugger layout in it
and a tab that has a command line in it instead of the GUI and it is a no mouse needed option to make all the other tabs jump in the single pane below the command line to do things that the GUIs cannot plus a help that has all the latest command line commands in it hmm deadly night shades of the Lisp Debugger ? i have never used a Lisp Debugger except in the 1980s they seem to insist on text only to this day why is text only better in some way ? or as good i saw in a magazine Linux or something a long time ago some guy running a Lisp repl Debugger and it looked pretty wild what he was describing could it open different GUIs? or something i still haven’t tried a Common Lisp repl Debugger yet DrRacket has(had) a single pane GUI Debugger maybe there could be a tab that removes the tab bar and replaces it with a command line ?
Before and After Methods like in this Dolphin Package supposedly or CLOS could be good for scripting into the Debugger? if you could before and after all Methods at once ?
A Debugger that can be scripted ? might be good ?
Hi Eliot --
From the top of my hat, here are things that might help finding the cause of that slowdown:
1. No stepping is involved in the debugger itself. Neither the outer model (Debugger) nor its embedded inspectors will receive a stepping call from Morphic. See Debugger >> #wantsStepsIn:.
2. Some direct stepping is involved in the debugger's text fields via TextMorph >> #onBlinkCursor. That can be turned off via: "Editor blinkingCursor: false". Existing text fields are not updated immediately, but there is code for that in PreferenceWizardMorph >> #toggleBlinkingCursor.
3. Syntax highlighting is updated on every code change, not selection change. Try disabling such highlights via "SHTextStylerST80 syntaxHighlightingAsYouType: false.". Existing text fields are updated automatically.
4. We chose to make URL highlighting work on mouse-move events. This may slow down your interactions with debugger text. Try removing the call to #mouseEnterOnTextAction: from TextMorph >> #mouseMove:.
5. For Trunk via Morphic-mt.2152, I just added "spy on action invocation" to each button's debug menu, which is accessible via the Morphic halo. This can help to better understand the slow-down in your image.
It seems very strange that a click on "step into" or "step over" takes many seconds... you can also use the halo to inspect the debugger's model to then evaluate: "MessageTally spyOn: [self stepInto]" or #stepOver or #stepThrough.
Hope this helps! Happy Squeaking :-)
Best, Marcel
Am 13.02.2024 02:32:47 schrieb Eliot Miranda eliot.miranda@gmail.com:
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
Hi Eliot,
On 2024. 02. 13. 2:32, Eliot Miranda wrote:
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.
For the parser part, you can print SHParserST80 benchmark. On my machine, in a fresh image, method sources read from the disk yields this:
Methods 64316 Total 2195.566ms Average 0.034ms Min 0.001ms 2 range(s) (MVCToolBuilderTests>>#testTreeWidgetID) Median 0.015ms 15 ranges (ClassInspectorTest>>#testPoolDictionaries) 80th percentile 0.041ms 56 ranges (PositionableStream>>#nextString) 95th percentile 0.107ms 136 ranges (FileList2>>#listForPattern:) 99th percentile 0.245ms 320 ranges (MorphicToolBuilder>>#buildPluggableDialog:) Max 62.335ms 128595 ranges (StrikeFont class>>#dejaVuSansBold13Data)
So, it is not very likely that the Shout parser would be causing any issues.
Best, Levente
P.S.: This is a good reminder that we should fix StrikeFont class>>#dejaVuSansBold13Data. This method is far larger than any other #dejaVuSansBold*Data (128586 elements vs 265), and there is no #dejaVuSansBold13Form method, while there's one for all other sizes, so presumably this font cannot be recreated. It's also quite a large blob to have around in the image.
_,,,^..^,,,_ best, Eliot
Hi Levente --
[...] StrikeFont class>>#dejaVuSansBold13Data [...]
That was an oversight. I remembered talking with Tobias back then which sizes we would need. 13 was not meant to be included. I removed the x-width data method.
Best, Marcel
Am 14.02.2024 14:27:28 schrieb leves leves@caesar.elte.hu:
Hi Eliot,
On 2024. 02. 13. 2:32, Eliot Miranda wrote:
Hi All,
I'm trying to debug an inlining edge case in the VM for thethreaded 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.
For the parser part, you can print SHParserST80 benchmark. On my machine, in a fresh image, method sources read from the disk yields this:
Methods 64316 Total 2195.566ms Average 0.034ms Min 0.001ms 2 range(s) (MVCToolBuilderTests>>#testTreeWidgetID) Median 0.015ms 15 ranges (ClassInspectorTest>>#testPoolDictionaries) 80th percentile 0.041ms 56 ranges (PositionableStream>>#nextString) 95th percentile 0.107ms 136 ranges (FileList2>>#listForPattern:) 99th percentile 0.245ms 320 ranges (MorphicToolBuilder>>#buildPluggableDialog:) Max 62.335ms 128595 ranges (StrikeFont class>>#dejaVuSansBold13Data)
So, it is not very likely that the Shout parser would be causing any issues.
Best, Levente
P.S.: This is a good reminder that we should fix StrikeFont class>>#dejaVuSansBold13Data. This method is far larger than any other #dejaVuSansBold*Data (128586 elements vs 265), and there is no #dejaVuSansBold13Form method, while there's one for all other sizes, so presumably this font cannot be recreated. It's also quite a large blob to have around in the image.
_,,,^..^,,,_ best, Eliot
squeak-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Kjell Godo -
leves -
Taeumel, Marcel -
Thiede, Christoph