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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200930/982c4cf5/attachment-0001.html>