MacOSX Performance

Tim Rowledge tim at sumeru.stanford.edu
Fri Jan 21 22:25:03 UTC 2005


Karsten Wolf <karstenwo at web.de> wrote:

> 
> Am 21.01.2005 um 14:34 schrieb Stéphane Conversy:
> 
> > I guess the problem comes from the display engine.
> >
> 
> Guessed right. Or more precisely It has to do with the fact that the vm 
> calls for a display update for every bitblt. Since these update calls 
> are interprocess calls on OSX (VM to WindowServer) they become very 
> expensive in terms of time if the vm does that for every pixel.
 
> You're seeing the slowness especially when drawing lines. In that case 
> the display update is called for every pixel which brings the

Wrong. Take a look at that code again.
BitBltSimulation>primitiveDrawLoop.  & >showDisplayBits. Note the
interpreter's use of deferDisplayBits. Note also that Morphic
frequently displays to a backing Form and then does a screen update in
a big chunk.

Display update performance might well be a performance bottleneck, but
not for your stated reasons.


>
> performance down to the 1% area. You won't see it in cases where the 
> update covers a bigger area. The FreeCell test (selecting game 1) 
> should be comparable to the windows vm.
> 
> > - the vm is the same for all machines,
> I think not. AFAIK the official windows vm has some kind of display 
> deferring included.

The vm is ~90% identical for all platforms. The platform specific code
is, surprise, platform specific. Platforms have different behaviours
when it comes to input handling and output handling. Even on the same
nominal platform a difference (and a non-trivial one) can arise from a
different graphics card or even just a driver.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful Latin Phrases:- Vescere bracis meis. = Eat my shorts.



More information about the Squeak-dev mailing list