Date: Tue, 19 May 2020 01:21:53 -0500
From: "Shaping" <[hidden email]>
To: "'Pharo Development List'" <[hidden email]>, "'Open
Smalltalk Virtual Machine Development Discussion'"
Subject: Re: [Vm-dev] [Pharo-dev] Squeak and Pharo speed differences
Content-Type: text/plain; charset="utf-8"
Another GUI-input speed observation:
If you click the scroll wheel once to shift the text contents of the pane, the visual effect is very fast. I cannot detect any latency; it certainly is not close to what I see for text insertion/deletion, cursoring, and double-click selection. The slower operations all involve getting a damage rect at a specific point based on cursor position or click position. The faster scrolling function doesn’t need to do that. It just grabs the entire visible rectangle minus one line, and blits it shifted down by one line, along with the one new line. That looks like an almost zero-cost collection of damage rects. It’s a simple, fast calculation. Collection of damage rects for the slower operations looks much more expensive. The events involved in both cases are delivered to the target handler with the same latency. The slowness or quickness seems to have after that.
Hence graphics output necessarily lags input on Morphic. So these speed differences have nothing to do with vm performance and everything to do with GUI architecture.
Both Squeak and Pharo show the same delay for text selection latency. The architecture difference is not likely causing that.
Given that both Pharo and Squeak useorphic and hence nothing have the same tender-in-step architecture isn’t the fact that they show the sane performance issue evidence that points to precisely this being the cause?
Yes, but not architecture, by which I think you mean the pushing of events versus the fixed-frequency regular loop in Morphic. I would expect a big variation in the Morphic case, but I don’t know what the fixed frequency is; it could well under the noise floor. My first thought would be that getting the damage rects is the problem, but I’ve not seen the code.
How do we index or look up the word rectangle to render? I’m think that is more likely the cause. Is a map created at method compile time and updated after text is moved during edits?
My understanding is that damage rectangles are retrieved,
Right, but this is the potentially slow part—the retrieving or perhaps more specifically mapping a point to a rectangle containing a contiguous sequence of non-whitespace character (a word).
combined to produce a smaller (non-overlapping?) set, and that the entire morph tree is asked to render within these damage rectangles. You can read the gods for yourself.
It’ll be a while.
I just tried some new experiments. I should have thought of these earlier. Character insertion and cursoring in any direction by one character have the same latency. Collecting the damage rectangle at the cursor position and around the selected word are both taking about the same time as far as I can tell with my eye, and this time is longer than in VW or any Windows app. But VW doesn’t use the Windows message queue directly. All incoming Windows events are converted to Smalltalk equivalents and are queued on the Smalltalk side. And it works well. Why not mimic that pattern to get the extra speed? Does something in Squeak/Pharo architecture prevent us from doing that?
How do we set a multi-process time profiler running so that we don’t need to eval blocks to get tallies. I just want to use the editor and watch method hit distribution. I see the Time profiler window; it seems to need a code snippet to work.
How is the JIT code cache cleared?
Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState.