J J writes:
 > The issue that triggered this whole thing about the primative was the fact 
 > that it was demonstrated that rolling you own count: using do: and a temp 
 > variable was faster then using the library count:.
 > 
 > This is a problem, yes?  The library count: shouldn't be 3 times slower (I 
 > think that was the number) then rolling your own.  Klaus has tried to come 
 > up with a solution to this.  Do you have another solution to it?

Exupery already optimises do: by a factor of 50%. At that point I
stopped because it was not providing any benefits for any of the large
benchmarks I'm tracking. I do this by optimising message send, return,
and byte code execution. My current implementation of value: is
possibly worse than the interpreters or equally as bad. Adding a fast
compiled value: to Exupery would be easy but there are no realistic
benchmarks that would benefit from it.

The library should also be readable. This is Smalltalk, we all read
the library code all the time. But I'm repeating myself. There is
a value judgement between readability and speed. We differ in I don't
feel speed is worth it at all costs.

Personally, I'd prefer a library that I can easily understand that is
fast enough for 99% of it's uses. That for 1% of cases, I need to use
a custom solution is an acceptable trade off for understandability.

I've spent many hours looking at Klaus's changes, I have not yet spent
enough time to be sure they are bug free. commonSend and return are a
messy part of the system. There is a lot of state tucked away in
globals that effects decision making. There are many infrequent cases
due to optimisations that are already there. When I talk about
maintainability issues I am talking about code that I am very familiar
with, have studied it both as code and in the debugger.

 > Now I understand your objection about not wanting to add a speed 
 > optimization that actually slows down the common case, but I don't see where 
 > the message sends get slower.  Does that have something to do with another 
 > primative being added?  Does every new primative add a speed hit?

The speed hit comes from the code in commonSend and
commonReturn. Adding a primitive, only effects performance when it's
executed.


As yet no-one has demonstrated a single practical use of occurencesOf:
where the speed difference would matter. No one has shown any
realistic benchmarks where speeding up do: and friends would matter.

We should remove the optimisation to ifNotNil: that is buggy unless
someone can provide realistic benchmarks where it matters. I would be
surprised if such code was in any critical inner loop. Try explaining
when the compiled version is used and when the byte code inlined
version is used to someone new to Smalltalk. If only one or two
cases need to be inlined then still remove it.

At some point, we've got to value maintainability and simplicity
otherwise the system will die. The issue here is one of values,
values that matter for the survivability, reliability, and
maintainability of the system. I care more about the values here
than the specific change.

Speed is not the ultimate goal. Speed is neither necessary nor
sufficient for Squeak's success. Speed does help though.

I want a system that is easy to change. Changes like Klaus's will
make it harder for the next person to change it. Klaus's ability to
make that change is worth a slight loss of performance. 

Bryce