Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!uhog.mit.edu!news.mtholyoke.edu!world!jhaungs
From: jhaungs@world.std.com (Jim Haungs)
Subject: Smalltalk SLOP/SMOP benchmarks: A follow-up
Message-ID: <D2819o.7zy@world.std.com>
Summary: There's a faster way to sort strings in PP VW.
Keywords: SLOP SMOP Smalltalk benchmarks ParcPlace
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 11 Jan 1995 03:20:11 GMT
Lines: 41


This is a followup to my benchmark post.

Remember how slow the sorting of strings was in ParcPlace VisualWorks?
Well, the engineers at ParcPlace have discovered where the bottleneck is.  
If you do a lot of string sorting, you'll want to use this trick.
Why this isn't the default behavior, I don't know...

In your sorting code, instead of:

	aSet asSortedCollection

instead write:

	aSet asSortedCollection: [:a :b | (a trueCompare: b) <= 0]

This will cause the trueCompare: method to be used instead of the
compare: method.  The trueCompare: method tries a primitive first, so for 
most Strings, the processing is done in the VM, for a radical increase 
in speed (almost 3x). The strange math (<= 0) is due to the fact that 
trueCompare: returns -1 or 0 or +1, depending on whether the 
left argument is lexically less than, equal, or greater than 
the right argument, respectively.

This "fix" puts ParcPlace at the top of the sorting heap (pardon 
the sordid metaphor), but it strikes me as something that should 
be fixed in the base classes, not hacked into every program.

Obviously, this code is also non-portable from Smalltalk to Smalltalk,
and in defense of the SLOP/SMOP benchmarks, they DID compile perfectly
on every platform.  They wouldn't if we changed the benchmark to use
this method.

Anybody from ParcPlace want to comment on why this is, or needs to be,
the way it is?

Cheers,
Jim



