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
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]
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@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@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
Hi Christoph,
On Sat, Sep 19, 2020 at 11:57 AM Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
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:
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.
Nice. What ever is TSTTCPW :-). But it strikes me that one way is to use addDeferredUIMessage:. The only tricky thing is not creating lots of these unnecessarily. But that could be done by checking if the deferred action queue is empty or not. E.g. rewrite this in doStep:
self contextStackIndex > 1 ifTrue: [self resetContext: newContext] ifFalse: [newContext == currentContext ifTrue: [self changed: #contentsSelection. self updateInspectors] ifFalse: [self resetContext: newContext]].
as, say,
self contextStackIndex > 1 ifTrue: [self resetContext: newContext] ifFalse: [newContext == currentContext ifTrue: [self scheduleUIUpdate] ifFalse: [self resetContext: newContext]].
add an inst var to hold the last deferred action, and then do something like
Debugger>>scheduleUIUpdate (lastScheduledUpdate notNil and: [WorldState lastDeferredUIMessage == lastScheduledUpdate]) ifTrue: [^self]. lastScheduledUpdate := [self changed: #contentsSelection. self updateInspectors]. WorldState addDeferredUIMessage: lastScheduledUpdate
For this we have to add the lastDeferredUIMessage accessor to all the relevant places, but it seems a nice pattern to me.
And of course, there is no need to refresh lastScheduledUpdate. It could be
Debugger>>scheduleUIUpdate lastScheduledUpdate ifNil: [lastScheduledUpdate := [self changed: #contentsSelection. self updateInspectors]]. WorldState lastDeferredUIMessage ~~ lastScheduledUpdate ifTrue: [WorldState addDeferredUIMessage: lastScheduledUpdate]
What do you think? :-)
What do you like?
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@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
Hi Eliot, these are interesting ideas! :-)
Your pattern is cool, it reminds me a little bit of the approach we are using for Shout, see SHTextStyler >> #styleInBackgroundProcess:.
It even more reminds me of Collection >> #do:displayingProgress:every:.
And last but not least, at a fundamental level, aren't we replicating the usual stepping logic from WorldState here?
In your approach, where do you process the scheduled messages? The problem is that we are running the simulation/execution code on the UI process. See this thread, too: http://forum.world.st/Debugging-of-other-processes-with-wait-tp5119965p51200...
I would not use #lastDeferredUIMessage unless we can rule out that any other client is communicating with the WorldState. Which we, afaik, never can rule out since the idea of the deferred messages is that you can have them scheduled from any background process.
It would be cool to develop some reusable logic that is applicable to different domains without expensive adaption. Maybe we should just add some static generic helper method for this?
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Samstag, 19. September 2020 21:36:57 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Christoph,
On Sat, Sep 19, 2020 at 11:57 AM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
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:174a7d2f503f456b1e51]
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.
Nice. What ever is TSTTCPW :-). But it strikes me that one way is to use addDeferredUIMessage:. The only tricky thing is not creating lots of these unnecessarily. But that could be done by checking if the deferred action queue is empty or not. E.g. rewrite this in doStep:
self contextStackIndex > 1 ifTrue: [self resetContext: newContext] ifFalse: [newContext == currentContext ifTrue: [self changed: #contentsSelection. self updateInspectors] ifFalse: [self resetContext: newContext]].
as, say,
self contextStackIndex > 1 ifTrue: [self resetContext: newContext] ifFalse: [newContext == currentContext ifTrue: [self scheduleUIUpdate] ifFalse: [self resetContext: newContext]].
add an inst var to hold the last deferred action, and then do something like
Debugger>>scheduleUIUpdate (lastScheduledUpdate notNil and: [WorldState lastDeferredUIMessage == lastScheduledUpdate]) ifTrue: [^self]. lastScheduledUpdate := [self changed: #contentsSelection. self updateInspectors]. WorldState addDeferredUIMessage: lastScheduledUpdate
For this we have to add the lastDeferredUIMessage accessor to all the relevant places, but it seems a nice pattern to me.
And of course, there is no need to refresh lastScheduledUpdate. It could be
Debugger>>scheduleUIUpdate lastScheduledUpdate ifNil: [lastScheduledUpdate := [self changed: #contentsSelection. self updateInspectors]]. WorldState lastDeferredUIMessage ~~ lastScheduledUpdate ifTrue: [WorldState addDeferredUIMessage: lastScheduledUpdate]
What do you think? :-)
What do you like? Best, Christoph ________________________________ Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda@gmail.commailto:eliot.miranda@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
-- _,,,^..^,,,_ best, Eliot
Hi Christoph,
On Sat, Sep 19, 2020 at 1:17 PM Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Hi Eliot, these are interesting ideas! :-)
Your pattern is cool, it reminds me a little bit of the approach we are using for Shout, see SHTextStyler >> #styleInBackgroundProcess:.
It even more reminds me of Collection >> #do:displayingProgress:every:.
And last but not least, at a fundamental level, aren't we replicating the usual stepping logic from WorldState here?
I don't think so. What we're doing is decouplng from it. But you could be right. It seems to me like an MVC/MVP pattern. The model is changing, but it only makes sense to change the display when the observer can represent the model. If one is in an animation system such as Morphic then the observer (V or V&P) only needs display the model when rendering the next frame, if the model has changed. So what we'd like is automatic filtering or buffering of the state the odel uses to announce it has changed. But we don't have that. We've just got SharedQueue. So a poor man's solution is to use it.
In your approach, where do you process the scheduled messages? The problem is that we are running the simulation/execution code on the UI process. See this thread, too: http://forum.world.st/Debugging-of-other-processes-with-wait-tp5119965p51200...
I would not use #lastDeferredUIMessage unless we can rule out that any other client is communicating with the WorldState. Which we, afaik, never can rule out since the idea of the deferred messages is that you can have them scheduled from any background process.
It would be cool to develop some reusable logic that is applicable to different domains without expensive adaption. Maybe we should just add some static generic helper method for this?
Well, take a look at what I commited to inbox. It soles the run to here problem, but does not fix fast clicking. So I'm just pointing you to it because it may be useful. I think you can focus on the problem better than I. But I'm here if you need to bounce ideas off me. Thanks for your energy here!!
Best,
Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com *Gesendet:* Samstag, 19. September 2020 21:36:57 *An:* The general-purpose Squeak developers list *Betreff:* Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Christoph,
On Sat, Sep 19, 2020 at 11:57 AM Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
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:
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.
Nice. What ever is TSTTCPW :-). But it strikes me that one way is to use addDeferredUIMessage:. The only tricky thing is not creating lots of these unnecessarily. But that could be done by checking if the deferred action queue is empty or not. E.g. rewrite this in doStep:
self contextStackIndex > 1 ifTrue: [self resetContext: newContext] ifFalse: [newContext == currentContext ifTrue: [self changed: #contentsSelection. self updateInspectors] ifFalse: [self resetContext: newContext]].
as, say,
self contextStackIndex > 1 ifTrue: [self resetContext: newContext] ifFalse: [newContext == currentContext ifTrue: [self scheduleUIUpdate] ifFalse: [self resetContext: newContext]].
add an inst var to hold the last deferred action, and then do something like
Debugger>>scheduleUIUpdate (lastScheduledUpdate notNil and: [WorldState lastDeferredUIMessage == lastScheduledUpdate]) ifTrue: [^self]. lastScheduledUpdate := [self changed: #contentsSelection. self updateInspectors]. WorldState addDeferredUIMessage: lastScheduledUpdate
For this we have to add the lastDeferredUIMessage accessor to all the relevant places, but it seems a nice pattern to me.
And of course, there is no need to refresh lastScheduledUpdate. It could be
Debugger>>scheduleUIUpdate lastScheduledUpdate ifNil: [lastScheduledUpdate := [self changed: #contentsSelection. self updateInspectors]]. WorldState lastDeferredUIMessage ~~ lastScheduledUpdate ifTrue: [WorldState addDeferredUIMessage: lastScheduledUpdate]
What do you think? :-)
What do you like?
Best, Christoph
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@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
-- _,,,^..^,,,_ best, Eliot
Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@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
Hi Eliot, hi all!
I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.
Best, Marcel Am 19.09.2020 23:00:33 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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 im Auftrag von Eliot Miranda 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
On Sep 29, 2020, at 1:07 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot, hi all!
I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.
<3 thank you, thank you, thank you!!
Best, Marcel
Am 19.09.2020 23:00:33 schrieb Levente Uzonyi leves@caesar.elte.hu:
Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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 im Auftrag von Eliot Miranda 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
Hi Marcel,
On Tue, Sep 29, 2020 at 1:07 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot, hi all!
I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen? I want to modify ContextInspector to cache the temp names for a given method because I believe this will speed up stepping a lot. However I couldn't find where the emphasis is applied so I'm worried that my cache may break something. If I can see where that is being done I have a better chance at avoiding breaking things.
Best, Marcel
Am 19.09.2020 23:00:33 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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 im Auftrag von Eliot Miranda 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
Hi Eliot,
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen?
By convention, inspector fields are defined in the category "fields - streaming". So you are probably searching for ContextInspector >> #streamTemporaryVariablesOn: or ContextVariablesInspector >> #streamTemporaryVariablesOn:?
Looking forward to your optimization! :-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Mittwoch, 30. September 2020 09:09:27 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Marcel,
On Tue, Sep 29, 2020 at 1:07 AM Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> wrote: Hi Eliot, hi all!
I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen? I want to modify ContextInspector to cache the temp names for a given method because I believe this will speed up stepping a lot. However I couldn't find where the emphasis is applied so I'm worried that my cache may break something. If I can see where that is being done I have a better chance at avoiding breaking things.
Best, Marcel
Am 19.09.2020 23:00:33 schrieb Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu>:
Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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 im Auftrag von Eliot Miranda 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
-- _,,,^..^,,,_ best, Eliot
Hi Christoph,
On Wed, Sep 30, 2020 at 2:27 AM Thiede, Christoph < Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Hi Eliot,
Can you point me to where in ContextInspector the emphasis for the temp
vars is chosen?
By convention, inspector fields are defined in the category "fields - streaming". So you are probably searching for ContextInspector >> #streamTemporaryVariablesOn: or ContextVariablesInspector >> #streamTemporaryVariablesOn:?
I found this code; I don't see any text emphasis going on. Where is the code that turns temp variables red when they're out of scope? Marcel?
Looking forward to your optimization! :-)
Best,
Christoph
http://www.hpi.de/
*Von:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com *Gesendet:* Mittwoch, 30. September 2020 09:09:27 *An:* The general-purpose Squeak developers list *Betreff:* Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Marcel,
On Tue, Sep 29, 2020 at 1:07 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot, hi all!
I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen? I want to modify ContextInspector to cache the temp names for a given method because I believe this will speed up stepping a lot. However I couldn't find where the emphasis is applied so I'm worried that my cache may break something. If I can see where that is being done I have a better chance at avoiding breaking things.
Best, Marcel
Am 19.09.2020 23:00:33 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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 im Auftrag von Eliot Miranda 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
-- _,,,^..^,,,_ best, Eliot
Hi Eliot,
you can have an inspector field's title be styled by sending "shouldStyleName: true" to it. The styling itself, then, is performed by the Inspector in #fieldList (or just browse the senders of #shouldStyleName), where the styler is invoked. Before styling the field list, the styler is configured in #aboutToStyle:requestor:/#updateStyler:requestor: where self doItContext is passed to the styler.
So tl;dr: Styling is always applied late (after the field list is constructed), you cannot break it by caching the temp names earlier. :-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Donnerstag, 1. Oktober 2020 20:33:08 An: The general-purpose Squeak developers list; Taeumel, Marcel Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Christoph,
On Wed, Sep 30, 2020 at 2:27 AM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Hi Eliot,
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen?
By convention, inspector fields are defined in the category "fields - streaming". So you are probably searching for ContextInspector >> #streamTemporaryVariablesOn: or ContextVariablesInspector >> #streamTemporaryVariablesOn:?
I found this code; I don't see any text emphasis going on. Where is the code that turns temp variables red when they're out of scope? Marcel?
Looking forward to your optimization! :-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda@gmail.commailto:eliot.miranda@gmail.com> Gesendet: Mittwoch, 30. September 2020 09:09:27 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Marcel,
On Tue, Sep 29, 2020 at 1:07 AM Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> wrote: Hi Eliot, hi all!
I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen? I want to modify ContextInspector to cache the temp names for a given method because I believe this will speed up stepping a lot. However I couldn't find where the emphasis is applied so I'm worried that my cache may break something. If I can see where that is being done I have a better chance at avoiding breaking things.
Best, Marcel
Am 19.09.2020 23:00:33 schrieb Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu>:
Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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 im Auftrag von Eliot Miranda 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
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
Hi Eliot, hi Christoph.
How is the current state of this issue? We did some recent improvements in the debugger. Yet, the styling of context variables can be still rather slow. Is it still noticeable?
Best, Marcel Am 01.10.2020 23:14:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Eliot,
you can have an inspector field's title be styled by sending "shouldStyleName: true" to it. The styling itself, then, is performed by the Inspector in #fieldList (or just browse the senders of #shouldStyleName), where the styler is invoked. Before styling the field list, the styler is configured in #aboutToStyle:requestor:/#updateStyler:requestor: where self doItContext is passed to the styler.
So tl;dr: Styling is always applied late (after the field list is constructed), you cannot break it by caching the temp names earlier. :-)
Best, Christoph [http://www.hpi.de/] Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Donnerstag, 1. Oktober 2020 20:33:08 An: The general-purpose Squeak developers list; Taeumel, Marcel Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy? Hi Christoph,
On Wed, Sep 30, 2020 at 2:27 AM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de [mailto:Christoph.Thiede@student.hpi.uni-potsdam.de]> wrote:
Hi Eliot,
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen?
By convention, inspector fields are defined in the category "fields - streaming". So you are probably searching for ContextInspector >> #streamTemporaryVariablesOn: or ContextVariablesInspector >> #streamTemporaryVariablesOn:?
I found this code; I don't see any text emphasis going on. Where is the code that turns temp variables red when they're out of scope? Marcel?
Looking forward to your optimization! :-)
Best, Christoph [http://www.hpi.de/] Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]> im Auftrag von Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> Gesendet: Mittwoch, 30. September 2020 09:09:27 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy? Hi Marcel,
On Tue, Sep 29, 2020 at 1:07 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Eliot, hi all!
I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen? I want to modify ContextInspector to cache the temp names for a given method because I believe this will speed up stepping a lot. However I couldn't find where the emphasis is applied so I'm worried that my cache may break something. If I can see where that is being done I have a better chance at avoiding breaking things.
Best, Marcel Am 19.09.2020 23:00:33 schrieb Levente Uzonyi <leves@caesar.elte.hu [mailto:leves@caesar.elte.hu]>: Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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 im Auftrag von Eliot Miranda 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
--
_,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
Recently I noticed a debugger that was very slow in general because its receiver inspector was showing a text with thousands of characters. Unfortunately, I cannot reproduce it ...
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Montag, 9. November 2020 09:06:31 An: squeak-dev Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Eliot, hi Christoph.
How is the current state of this issue? We did some recent improvements in the debugger. Yet, the styling of context variables can be still rather slow. Is it still noticeable?
Best, Marcel
Am 01.10.2020 23:14:48 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
Hi Eliot,
you can have an inspector field's title be styled by sending "shouldStyleName: true" to it. The styling itself, then, is performed by the Inspector in #fieldList (or just browse the senders of #shouldStyleName), where the styler is invoked. Before styling the field list, the styler is configured in #aboutToStyle:requestor:/#updateStyler:requestor: where self doItContext is passed to the styler.
So tl;dr: Styling is always applied late (after the field list is constructed), you cannot break it by caching the temp names earlier. :-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Eliot Miranda eliot.miranda@gmail.com Gesendet: Donnerstag, 1. Oktober 2020 20:33:08 An: The general-purpose Squeak developers list; Taeumel, Marcel Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Christoph,
On Wed, Sep 30, 2020 at 2:27 AM Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:
Hi Eliot,
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen?
By convention, inspector fields are defined in the category "fields - streaming". So you are probably searching for ContextInspector >> #streamTemporaryVariablesOn: or ContextVariablesInspector >> #streamTemporaryVariablesOn:?
I found this code; I don't see any text emphasis going on. Where is the code that turns temp variables red when they're out of scope? Marcel?
Looking forward to your optimization! :-)
Best,
Christoph
http://www.hpi.de/ ________________________________ Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda@gmail.commailto:eliot.miranda@gmail.com> Gesendet: Mittwoch, 30. September 2020 09:09:27 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Can we make computing the local variables in the debugger lazy?
Hi Marcel,
On Tue, Sep 29, 2020 at 1:07 AM Marcel Taeumel <marcel.taeumel@hpi.demailto:marcel.taeumel@hpi.de> wrote: Hi Eliot, hi all!
I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.
Can you point me to where in ContextInspector the emphasis for the temp vars is chosen? I want to modify ContextInspector to cache the temp names for a given method because I believe this will speed up stepping a lot. However I couldn't find where the emphasis is applied so I'm worried that my cache may break something. If I can see where that is being done I have a better chance at avoiding breaking things.
Best, Marcel
Am 19.09.2020 23:00:33 schrieb Levente Uzonyi <leves@caesar.elte.humailto:leves@caesar.elte.hu>:
Hi Christoph,
On Sat, 19 Sep 2020, Thiede, Christoph wrote:
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:
What was it exactly that you profiled?
The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> #getSource. The rest of the tree is not visible, but these methods have nothing to do with parsing or styling, they initialize the parser and normally should take <1 ms.
Also, why is the decompiler producing the source code?
[IMAGE]
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).
You may want to try compiling a VM where FilePlugin's CreateFile does not set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file reading performance.
Levente
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 im Auftrag von Eliot Miranda 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
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
squeak-dev@lists.squeakfoundation.org