>>> When we re-coded our terminology engine in C, a 24-hour knowledge
>>> base compile went down to 7 minutes.  Extreme, I know, but can the
>>> interpreted-language and OO communities do anything about this?

Hmm, I doubt that such a big difference can be made only by compiling. There
was probably a good deal of logical slack that was eliminated as well. The
general point that logic is more important than compiling has been made well
by others. This is from Kent Beck:

> A VisualWorks customer was very concerned about the performance of their
> system. They were concerned that all the horror stories they heard about
> Smalltalk being too slow for real systems were true. It seemed that the
> fundamental section of their system was taking minutes to do anything, and
> they needed it to take seconds. They couldn¹t figure out what was taking so
> long no matter how hard they tried.
> In a last ditch effort to figure out whether their work could be salvaged,
> Dave Leibs, Smalltalk performance guru from ParcPlace Systems, Inc. was called
> in for a day of consulting. They quickly described an overview of what they
> were trying to do. Nothing stood out to Dave as anything that would bring
> Smalltalk to its knees. So, he said,
> "Where did the Profiler indicate most of the time was being spent?"
> "What¹s the Profiler?"
> So he spent the next 30 minutes or so explaining what the Profiler was and
> helping them install it.
> He then ran the profiler on the section of code in question and found it was
> spending more than 98% of it¹s time in Date>>printOn:. Dave thought for a
> second what might be so slow about Date>>printOn: and felt it should not cause
> so great a problem. So, he looked a little higher up the profile tree and
> examined the containing method.
> He noticed the expression ŒDate today printString¹ inside of a loop. So he
> chose an Experiment and pulled the expression out of the loop, storing the
> value in a temporary variable which he then used inside the loop. Ten minutes
> after running the Profiler for the first time, he ran the code again. This
> critical section of code that was central to the client¹s system now took less
> than a second.
> Dave then turned to his hosts and said, "So, what are we going to do for the
> rest of the day?"

I recommend the whole piece:

Lazy Optimization: 
Patterns for Efficient Smalltalk Programming

http://www.rolemodelsoft.com/patterns/lazyopt.htm

H