[squeak-dev] Re: [Pharo-dev] String >> #=

Eliot Miranda eliot.miranda at gmail.com
Tue May 27 04:45:18 UTC 2014


Hi Phillipe,


On Mon, May 26, 2014 at 12:51 AM, Philippe Marschall <
philippe.marschall at netcetera.ch> wrote:

> Hi
>
> I have been investigating why Dictionary look up performance with String
> keys is not as good as I would expected. Something I noted is that String
> >> #= is implemented in terms of #compare:with:collated:. There is no short
> circuit if Strings are not the same size. In my case some Strings have the
> same prefix but a different length eg 'Content-Type' and 'Content-Length'.
> In that case a #compare:with:collated: is performed even though we know in
> advance the answer will be false because they have different sizes.
>

Why not rewrite

String>>= aString
"Answer whether the receiver sorts equally as aString.
The collation order is simple ascii (with case differences)."
 aString isString ifFalse: [ ^ false ].
^ (self compare: self with: aString collated: AsciiOrder) = 2

as

String>>= aString
"Answer whether the receiver sorts equally as aString.
The collation order is simple ascii (with case differences)."

(aString isString
and: [self size = aString size]) ifFalse: [^false].
^ (self compare: self withSize: with: aString collated: AsciiOrder) = 2

?

One /could/ add a replacement compare:with:collated:
primitive primitiveCompareString which took the sizes as arguments to avoid
asking twice.  But it wouldn't be safe.  One could abuse the primitive and
lie about the size.  So I suspect it is best to add the size check to
String>>#= and accept the duplication of the primitive finding the sizes of
the two strings.  The cost in the primitive is minimal.  A WideString
version of the primitive might pay its way, but if Spur and Sista arrive
soon the primitive shouldn't be faster than the optimised Smalltalk code.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140526/44393273/attachment.htm


More information about the Squeak-dev mailing list