<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:large">Hi Marcel,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 29, 2020 at 1:07 AM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="gmail-m_273208692865051878__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">

                                        Hi Eliot, hi all!<div><br></div><div>I fixed the issue with Tools-mt.989. The logic was already there in #runUntil.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:large">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.</div><div class="gmail_default" style="font-size:large"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div id="gmail-m_273208692865051878__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)"><div><br></div><div>Best,</div><div>Marcel</div><div></div>

                                        <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">

                        <p style="color:rgb(170,170,170);margin-top:10px">Am 19.09.2020 23:00:33 schrieb Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Christoph,

<br>

<br>On Sat, 19 Sep 2020, Thiede, Christoph wrote:

<br>

<br>> 

<br>> Hi Eliot,

<br>> 

<br>> 

<br>> 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:

<br>

What was it exactly that you profiled?

<br>

<br>The screenshot shows that 76.9% was spent in #initializeVariablesFromContext, 

<br>of which 52.5% of the time was spent in CompiledMethod(CompiledCode) >> 

<br>#getSource. The rest of the tree is not visible, but these methods have 

<br>nothing to do with parsing or styling, they initialize the parser and 

normally should take <1 ms.

<br>

Also, why is the decompiler producing the source code?

<br>

<br>> 

<br>> 

<br>> [IMAGE]

<br>> 

<br>> 

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

<br>

<br>You may want to try compiling a VM where FilePlugin's CreateFile does not 

<br>set the FILE_FLAG_SEQUENTIAL_SCAN flag, and see if it helps with file 

reading performance.

<br>

<br>

<br>Levente

<br>

<br>> 

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

<br>> 

<br>> What do you think? :-)

<br>> 

<br>> Best,

<br>> Christoph

<br>> 

<br>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________

<br>> Von: Squeak-dev <u></u> im Auftrag von Eliot Miranda <u></u>

<br>> Gesendet: Samstag, 19. September 2020 20:17:12

<br>> An: The general-purpose Squeak developers list; Taeumel, Marcel

<br>> Betreff: [squeak-dev] Can we make computing the local variables in the debugger lazy?  

<br>> Hi Marcel,

<br>> 

<br>>     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

<br>> debugging difficult.

<br>> 

<br>> As an example use this:

<br>> 

<br>> | samples sineTable sound |

<br>> "1 second of A below middle C (220Hz). 16000 / 220 is 72.72 recurring"

<br>> sineTable := SoundPlayer sineTable: 73.

<br>> sineTable doWithIndex: "And let's not deafen anyone..."

> [:sample :index| sineTable at: index put: sample // 4].

<br>> samples := SoundBuffer new: 16000.

<br>> 1 to: samples size by: sineTable size do:

<br>> [:i| samples replaceFrom: i to: (i + sineTable size - 1 min: 16000) with: sineTable startingAt: 1].

<br>> 1 to: 146 do:

<br>> [:i|

<br>> samples at: i put: ((samples at: i) * i / 146) asInteger.

<br>> samples at: 16001 - i put: ((samples at: 16001 - i) * i / 146) asInteger].

<br>> sound := SampledSound

<br>> samples: samples

<br>> samplingRate: 16000.

<br>> sound := MixedSound new

<br>> add: sound pan: 0.25;

<br>> add: sound pan: 0.75;

<br>> yourself.

<br>> sound computeSamplesForSeconds: sound duration

<br>> 

<br>> 

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

<br>> 

> Now do the same in a contemporary trunk image.  It takes almost 6 seconds.

<br>> 

<br>> 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

<br>> far.

<br>> 

<br>> 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

<br>> - when Morphic updates, and

<br>> - when the context changes?

<br>> 

<br>> 

<br>> _,,,^..^,,,_

<br>> best, Eliot

<br>> 

<br>><u></u><u></u></div></blockquote></div><br>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>