> On 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.

<3 thank you, thank you, thank you!!


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