Hi Levente --
[...] StrikeFont class>>#dejaVuSansBold13Data [...]
That was an oversight. I remembered talking with Tobias back then which sizes we would need. 13 was not meant to be included. I removed the x-width data method.
Best, Marcel
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