Hi Christoph,

On Wed, Sep 30, 2020 at 2:27 AM Thiede, Christoph <
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> im
> Auftrag von Eliot Miranda <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>
> 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>:
>> 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/5a079258/attachment-0001.html>