Dorado bytecodes per second

Alejandro F. Reimondo aleReimondo at smalltalking.net
Sat Apr 30 17:14:50 UTC 2005


Hi Andres,
I agree with you in all you have said;
 but the only way (I know) to "reduce
 methods size" is acting on people and
 not focusing on "tools" or "languages". [*]
Each time we talk about Squeak as a device/tool
 (or instructing childs), we are not considering
 people (or adults).
We are leaving they out. The same politics of
 exclusion that is applyed to people that can´t
 buy a new/fast computer.
Each time we think in terms of machine perfomance
 we are no talking about an ambience, we are only
 talking about techniques to make machines work faster.
IMHO, if we want to stop thinking and start
 acting on "people topics", it is important that
 we focus our attention in regional/local acts
 and the way that people can realize their needs (by
 their own way).
We must not continue doing the same mistakes
 of thinking globally and acting globally and/or locally.
(sorry if anyone think that the conversation
 is going too much off topic)
cheers,
Ale.
[*] Small method sizes is a side effect, not a goal.


----- Original Message ----- 
From: "Andres Valloud" <sqrmax at optonline.net>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, April 30, 2005 10:53 PM
Subject: Re[2]: Dorado bytecodes per second


> Hello...
>
> AR> That's not to say we should throw away speed but the patterns
> AR> really have changed. For example, we use "foo isNil" without even
> AR> realizing that doing that is some 30 times slower than the
> AR> equivalent "foo == nil".
>
> A community unwilling to send a message?  This is Smalltalk, right?
>
> The focus should be more along the lines of "why do we need to check
> these things?".  Every check like that is expensive, regardless of
> whether it executes fast or not.  It's even faster not to need to
> check at all --- to remove the need for ifTrue:/ifFalse:.
>
> That usually requires short methods, clean code, crystal clear design,
> enough classes to model the special cases without having to inline
> ifTrue:/ifFalse: everywhere... and especially, no more
> spaghetti-interlaced frameworks.
>
> In my opinion, these are things that, collectively, we have failed to
> keep in mind.  And we will keep paying the price, with interests,
> until we change.
>
> -- 
> Best regards,
>  Andres                            mailto:sqrmax at optonline.net
>
>




More information about the Squeak-dev mailing list