Hello Tim,

I've usually found that most people end up optimizing code with
profilers when
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
percentage of
message sends unnecessarily, never caching a results and instead
reinvoking code,
doing calculations of invariants inside of loops and so on. (I remember
one horror
story that wasted 29 times as much time and memory as necessary and
another where
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
implementation to
the second and sometimes there's enough time to get it to the last
stage. That's
when I'll put a Smalltalk implementation up against any C++ code any day
of the
week.

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
the cycle
eaters.

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
and it
makes for a great IDE so it should stay. Most performance problems are
caused by
people not applying proper design principles and building the components
themselves instead of relying on general solutions regardless of how
much overhead
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
to do
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
TRec from
a stream "window" open over over the file! Idiots! They got lazy when /V
Win and
/V PM came out, forgot what they has learned in /V and /V 286 and
Digitalk stuff
wasn't the same after that.)

-Charles-A.

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
save X
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
to know
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
out vacation
requests to HR, we never knew when we were supposed to come to work or
when we
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.