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 at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at 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 at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at 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 at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com<mailto:eliot.miranda at 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 at hpi.de<mailto:marcel.taeumel at 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 at caesar.elte.hu<mailto:leves at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201001/48dcb0f0/attachment.html>