Am 14.02.2024 14:27:28 schrieb leves <leves@caesar.elte.hu>:

Hi Eliot,

On 2024. 02. 13. 2:32, Eliot Miranda wrote:
> Hi All,
>
>     I'm trying to debug an inlining edge case in the VM for the
> threaded VM that Leon is doing. The debugger is unusably slow (steps
> taking 10 seconds, etc).  I've raised this issue before but was brushed
> off.  I suspect somewhere in the new (last two years?) highlighting code
> is taking a lot of time.  Would the author(s) please provide me with
> some snippets of code i can use to try and measure performance? And/or
> would anybody be willing to pair (I'm on PST) in trying to get to the
> bottom of this?  It's extremely frustrating to try and work when the
> debugger is unusable.

For the parser part, you can print SHParserST80 benchmark. On my
machine, in a fresh image, method sources read from the disk yields this:

Methods 64316
Total 2195.566ms
Average 0.034ms
Min 0.001ms 2 range(s) (MVCToolBuilderTests>>#testTreeWidgetID)
Median 0.015ms 15 ranges (ClassInspectorTest>>#testPoolDictionaries)
80th percentile 0.041ms 56 ranges (PositionableStream>>#nextString)
95th percentile 0.107ms 136 ranges (FileList2>>#listForPattern:)
99th percentile 0.245ms 320 ranges
(MorphicToolBuilder>>#buildPluggableDialog:)
Max 62.335ms 128595 ranges (StrikeFont class>>#dejaVuSansBold13Data)

So, it is not very likely that the Shout parser would be causing any issues.


Best,
Levente

P.S.: This is a good reminder that we should fix StrikeFont
class>>#dejaVuSansBold13Data. This method is far larger than any other
#dejaVuSansBold*Data (128586 elements vs 265), and there is no
#dejaVuSansBold13Form method, while there's one for all other sizes, so
presumably this font cannot be recreated.
It's also quite a large blob to have around in the image.

>
> _,,,^..^,,,_
> best, Eliot
>
>