String compare performance
Michel Fortin
michel.fortin at michelf.com
Sun Nov 28 18:11:00 PST 2010
On 2010-11-28 20:57:38 -0500, bearophobic <notbear at cave.net> said:
> Stewart Gordon Wrote:
>
>> On 27/11/2010 23:04, Kagamin wrote:
>>> bearophile Wrote:
>>>
>>>>> Also, is there a way to bit-compare given memory areas at much
>>>>> higher speed than element per element (I mean for arrays in
>>>>> general)?
>>>>
>>>> I don't know. I think you can't.
>>>
>>> You can use memcmp, though only for utf-8 strings.
>>
>> Only for utf-8 strings? Why's that? I would've thought memcmp to be
>> type agnostic.
>>
>> Stewart.
>
> D community is amazing cult of premature optimization fans. Any one of
> you heard of canonically equivalent sequences? The integrated Unicode
> support is a clusterfuck. Please do compare ASCII strings with memcmp,
> but no Unicode. Where did the original poster pull this problem from,
> his ass? "My system runs 100,000,000,000 instructions per second, but
> this comparison of 4 letter strings uses 5 cycles too much! This is the
> only problem on the way to world domination with my $500 Microsoft Word
> clone!". No wait, the problems are completely imaginatory.
Comparing unicode UTF-* strings using memcmp is fine as long as what
you want to know is whether the code points are the same. If your point
was that per-code-point comparisons aren't the right way to compare
Unicode strings (in most situations), then I support this view too.
Though if that's what you wanted to say, you could have made your point
clearer.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list