Subject: Re: improving the string library
From: Mike Nordell (firstname.lastname@example.org)
Date: Fri Dec 22 2000 - 02:59:38 CST
Tomas Frydrych wrote:
> UT_UCS_strcmp: 350%
What if it was coded better? Like:
UT_sint32 UT_UCS_strcmp(const UT_UCSChar* left, const UT_UCSChar* right)
UT_sint32 ret = 0;
while (!(ret = *left - *right) && *right)
if (ret < 0)
ret = -1;
else if (ret > 0)
ret = 1 ;
This change would probably be at least some gain, would be portable and
would not force us to use assembler with all the nightmares that is. If it
is that many library functions are really slow, why not go to the source?
Perhaps submitting a patch to the glibc maintainers?
Hand-optimizing code today is quite hard, especially considering
out-of-order execution, not stalling pipes and so on.
> UT_UCS_strlen: 250%
What's the reason not to use wcslen (ANSI)?
But if we are to use this one, what about the following impl., would that be
UT_uint32 UT_UCS_strlen(const UT_UCSChar * string)
const UT_UCSChar* end = string;
while (*end++) ;
return (UT_uint32)(end - string - 1);
> UT_UCS_strstr: 44%
Though looking at our implementation of it suggests to me that it's not as
efficient as it could be (it's *really* bloated). What about the following,
how does this compare in speed? (not to mention the fact that this impl. is
UT_UCSChar* UT_UCS_strstr(const UT_UCSChar* str1, const UT_UCSChar* str2)
const UT_UCSChar* cp = str1;
const UT_UCSChar* s1 = cp;
const UT_UCSChar* s2 = str2;
while ( *s1 && *s2 && !(*s1-*s2) )
> The Linux system strcmp and strlen (which AbiUses) have been
> written in asm, but not fully optimised. strstr is, I think, written in C,
> and so are the rest; the 200-300% speed up on the C
> implemantions is in my experience not unusual.
Then I'd say that the optimizer in that compiler needs to be, well,
Perhaps the functions are coded in a way that don't let the optimizer do its
stuff (like aliasing pointers)?
/Mike - please don't cc
This archive was generated by hypermail 2b25 : Fri Dec 22 2000 - 02:57:56 CST