Iteration Speed, Collections, and speed

Andrew C. Greenberg werdna at mucow.com
Thu Jan 31 03:19:09 UTC 2002


I'll echo Doug's responses to Mark's objections, but will add that, in 
practice, many of the most critical iterations in Smalltalk applications 
are inlined, can be sped up [but ONLY AFTER profiling shows the gain is 
worth it] with refactoring and moving code to a specialized Collection 
method to exploit such inlining, and truly deep implied iterations 
[again ONLY AFTER profiling shows the gain is worth it, and the speedup 
is really worth the price] (such as BitBlt) can be readily handled 
through primitives, direct or pluggable.

In short, Squeak is frighteningly fast for most applications than one 
would expect knowing it to be what it is, but clearly not faster than 
straight C code.  On the other hand, just consider basic ideas such as a 
GUI, and how the powerful expressive value of a pure, late-bound, OO 
language gains in building complex applications, reducing the only real 
requirement for speed (pushing pixels on the screen) to a core primitive.

Optimizations that inhere in a programming language do make it easier to 
code fast code, but they often make it harder to code code.  The nice 
thing about coding Smalltalk (see the preface to my chapter in the 
nuBlue book) is that you can live in the broad environs of a system like 
Squeak, trivially profile, and only after you have gained ALL that 
productivity, spend some time refactoring to isolate the REAL 
performance problems, and then just code that in the inferior, "but 
faster to code," languages of your choice.  This gives the best of all 
worlds.  In practice, you find yourself wanting to write plugins far 
less frequently than you think you might.  (This said by a plugin 
addict.)

On Wednesday, January 30, 2002, at 07:36 PM, Doug Way wrote:

>
> Mark Mullin wrote:
>>
>> OK, I've gone and put my foot in it, I make one or two little comments 
>> about
>> iterators and people just jump all over my case   :-)
>>
>> What I mean to say is that for iterated collections such as ordered
>> collection, the process of adding and searching the collection is
>> significantly more expensive than in a lower level compiled language 
>> such as
>> C++.  I'm not denying the benefits of 1st class oop, garbage 
>> collection, or
>> all the other great things I get, I'm just observing on a performance
>> number.
>
> Understood.  I'd just have to pipe in along with Bijan that, when doing 
> basic collection operations and looping, I'd say the term "horrible" 
> would be reasonable to describe the usability/convenience of (explicit) 
> Java/C++ iterators relative to the implicit iteration in Smalltalk.
>
> In Java/C++, iterating through a collection requires setting up an 
> explicit Iterator object which often involves 3-4 times the amount of 
> code of the Smalltalk equivalent, especially when you consider select:, 
> collect:, detect:, etc.  In dealing with Java every day, this is 
> probably at or near the top of the list of things that slow down my 
> productivity.  (Up there with the primitive types problem.  Maybe I 
> just deal with Collections a lot.)  This article describes the issue 
> pretty well:  
> http://softwaredev.earthweb.com/java/sdjjavase/article/0,,12395_628951,00.
> html
>
> But yeah, performance is a different issue.
>
>> What this means in using Squeak is that you can't opt out to the C++ 
>> dumb
>> ass solution of "I got a list of 10K items, I'll just grovel through 
>> them to
>> find the one I want."  What is ignorable in C++ is a slow mover in
>> Smalltalk.
>
> I think much of the problem is that some collection operations just 
> haven't really been optimized much in Squeak yet.  For example, Scott 
> Crosby recently did some work with vastly improving the performance of 
> large Sets... this stuff will hopefully make its way into 3.3alpha in 
> one form or another.
>
> Some other Smalltalks such as VisualWorks have had most of their 
> collection operations pretty well optimized, so it's not necessarily a 
> language problem.  Generally, I'd expect this situation in Squeak to 
> improve as more people do real work with larger collections.
>
> - Doug Way
>   dway at riskmetrics.com
>




More information about the Squeak-dev mailing list