[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
|