Posted by
Schwab,Wilhelm K on
Jan 16, 2005; 9:45pm
URL: https://forum.world.st/The-cost-of-sending-a-message-tp3372722p3372729.html
Fernando,
> This code is form the dolphin companion. It's a method of the Driver
> class, that also understands the methods firstname, surname and name.
> All of them return Strings.
>
> setName
> "Create the name from the surname and firstname.
> This method is called when either of them changes."
> | tmpName |
> tmpName := String name.
> self surname notNil ifTrue: [tmpName := self surname].
> (self firstname notNil and: [self firstname notEmpty])
> ifTrue: [ tmpName := self firstname, ' ', tmpName ].
> self name: tmpName.
>
> This method calls several times the surname and firstname, which
> haven't changed between calls.
That is a very valid observation, but how often is #setName called?
Would the logical change make any real difference?
A way to find out would be to run code under Ian's profiler. Machines
have gotten faster over the past several years, to the point that a
millisecond is really quite a long time, so you might want to profile a
loop that does a particular job many times.
Dan Ingalls et al. were faced with making something run on much slower
hardware [1] than we have now. The 275 kilobytes (k, not M) of RAM he
needed was almost unthinkable in those days. They did it in part by
making the common things very efficient, and not paying too much
attention to the rare stuff. You can see that to this day with
Smalltalk code that runs when a primitive fails; some of it simply
signals an error, other times it does something "tricky" that would be
much harder to code in a primitive than in Smalltalk.
There is also the standard advice:
(1) make it run
(2) make it correct
(3) make it fast
Do them in that order.
[1] IIRC, Alan Kay has commented that modern caching pays little
attention to the lessons learned in the 60's, making the actual
throughput not nearly so large as one would expect looking at the clock
speeds. Specifics/references would be greatly appreciated.
> For someone used to VB this si a bit surprising, as using a temp
> variable to cache those values is much faster than calling a method
> (due to com overhead).
It's not just COM overhead; it's Automation overhead in many cases.
> Is this the usual Smalltalk way? Is the cost of method calling
> negligeable?
As Ian said, a running image sends a lot of messages, so implementors
try to make it efficient. However, any cost will eventually add up to
something noticeable. You are wise to pay attention to the efficiency
of code, but note that you can typically get a lot further by following
the three steps avove, in order. They are partly based on the reality
that many projects are throw-aways and do not require tuning (Smalltalk
will allow you to accomplish them MUCH faster than C* folks), and also
on the long-standing observation that programmers are typically have
very poor intuition when it comes to identifying performance
bottlenecks. Get something running, and IF the performance is not to
your needs or liking, use a profiler to find out why and fix it.
Note that this soewhat cavalier attitude would be riskier in C*, as
design changes are often necessary. However, by the time you get to
step (3), you should have units test that will help you get back to step
(2) after you make the design changes.
Keep in mind that you can always fall back on a C/C++ DLL for situations
that need very high performance. However, you should resort to that
only when you are certain it is necessary, or there is some other reason
(e.g. existing code for numerical analysis, etc.) to use another
language. #setName will not be likely to require a DLL.
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]