Timers, Stepping, Co-routines, and Performance in Squeak..... (was
Re: Timers & Stepping)
crovira at wt.net
Tue Mar 21 20:33:08 UTC 2000
I've usually found that most people end up optimizing code with
they should be optimizing by designing a better solution (read: implementing
closer to solving the problem-at-hand.)
There are things I've ripped out of code that were doing a fair
message sends unnecessarily, never caching a results and instead
doing calculations of invariants inside of loops and so on. (I remember
story that wasted 29 times as much time and memory as necessary and
most of the machine time was entirely wasted [never sort if its not necessary])
You have to learn to think about the design.
The agage runs:
First get it to work at all.
Secondly get it to work fast.
Last get it to work small.
Most people have enough trouble with the first. I usually get an
the second and sometimes there's enough time to get it to the last
when I'll put a Smalltalk implementation up against any C++ code any day
I've done some things in Smalltalk (/V, /V286, /V Win, /V PM and VSE)
that ran so
fast that I ran things twice because I couldn't believe they'd actually completed.
Smalltalk can really, really do some amazing things in terms of
performance if you
can get the code stream-lined (in line with the problem,) and eliminate
Yes the Squeak! VM could stand to be 30% tighter. Yes the images are
filled with a
lot of resource waste makers but the image is not execution-time waste
makes for a great IDE so it should stay. Most performance problems are
people not applying proper design principles and building the components
themselves instead of relying on general solutions regardless of how
they might invoke.
Anybody who thinks that ANY Smalltalk has ever been suitable for delivering
solutions "right out of the box" is sadly mistaken. But you can get it
beautiful things and if you know how to optimize the design of the implementation
and then the implementation, it can do them very fast.
There were some design points in /V that really sucked, like pulling the entire
content of a file regardless of how big when you can only display a few
K at once,
(that killed /V Mac for me because they used a TRec instead of filling a
a stream "window" open over over the file! Idiots! They got lazy when /V
/V PM came out, forgot what they has learned in /V and /V 286 and
wasn't the same after that.)
My second boss was a wiz-bang FORTRAN programmer. He could also take a program
apart and tell you to move code from one place to another because you'd
cycles. He was God's gift to optimization. He taught me how to think optimally
right from the design on out. He was also a major pain-in-the-ass. A "quick
change" took a week. An "Easy change" took two weeks and you never saw the
[expletive deleted] end of a "Quick and Easy Change."
Unforfunately, as a department manager, he really sucked. I learned a
lot but I
also learned that a good boss needs to know more than MY craft. He needs
some administration as well. I'm very ambivalent about having ever
worked for SSR.
On the one hand, he forgot to sign up for the pension plan, to submit
requests to HR, we never knew when we were supposed to come to work or
were likely to get home, etc. On the other hand, the man could CODE! And
he did it
with his mouth open and all you had to do was listen.
More information about the Squeak-dev