Timers, Stepping, Co-routines, and Performance in Squeak..... (was Re: Timers & Stepping)
Dan.Ingalls at disney.com
Wed Mar 22 02:24:10 UTC 2000
"Lex Spoon" <lex at cc.gatech.edu> wrote...
>On my computer, 73% of the CPU time is taken up by GrafPort>>fillRect:.
>Thus for the task of redrawing a typical display, less than 27% of the
>time is spent executing bytecodes. (And it's probably not even that
>much). From this quick test, the single biggest thing that could speed
>up Morphic redisplays is an even faster BitBlt.
>Note that even in C, you eventually defer to hand-coded assembler, and
>in turn assembly must eventually defer to custom hardware. No amount of
>VM hackery is going to remove this "primary mechanism". It's been a
>fundamental part of computing ever since "general purpose CPU's" were
Faster Blts are always good, but there's still plenty of room for cleverness. For instance, sparked by recent comments, I just made dragging windows go about twice as fast in morphic by being more careful about whether the dragee has holes or translucency (if not, you can use the considerably faster store mode of BitBlt). Coming soon to an update server near you.
The thing I love about Squeak is that it's like a living encyclopedia of stuff that all works, but that can all be played with. If you're serious about speeding things up, there are *all sorts* of opportunities to think outside the box. What I did for dragging is one example. Another is that in some cases morphic displays bottom to top for simplicity, but in others it goes top to bottom because opacity frequently implies that you don't have to display what's underneath. Also damage rectangles minimize the amount of redrawing, but there is logic to merge them when it may be quicker to do one big one than twenty little ones.
jeff.szuhay at pstnet.com wrote...
>I agree with Lex on this one.
> (Determine features.)
> Make it work.
> Make it stable.
> Make it fast.
> (rinse, repeat)
I think Jeff's last line is as important as all the rest. It takes a long time to develop a real intuition about complex systems. Goal-directed progress (through these steps) is typically very much in the pink plane, making things work, and making them fast enough. And usually that's where the work stops. It's in the loop back, after you understand all the things that are needed and how they interact and what is and is not important in the final analysis, that you can take a fresh cut in the blue plane, merge three different stategies, and end up with something much simpler and possibly more general.
Needless to say, this is where we are right now with morphic. I feel good about the core of morphic that has remained very simple, and about the many ways in which it has been stressed and pretty much met the challenge. Now all we have to do is fold all that we have learned into a rewrite that gives us simplicity, generality and speed all at once.
More information about the Squeak-dev