HEADS DOWN

[Sean C. Farley]

On Wed, 9 May 2007, Bruce Evans wrote:

> On Wed, 9 May 2007, Andrey Chernov wrote:
>
>> On Tue, May 08, 2007 at 04:37:03PM -0500, Sean C. Farley wrote:
>>>  Would it be preferred to go ahead to use strlen() in preparation
>>>  for a faster strlen() in the future?
>> ...
>> we can use strlen() in preparation for the future.
>
> Yes, it is better to use library functions if they do (almost) exactly
> what is wanted.
>
>>>  I would still use the inline'd version when counting characters
>>>  while watching for an '=' character.  Or should it also be changed
>>>  to perform a strlen() and then a strchr()?
>> 
>> Combined strlen()+strchr() will be slower in any case than single
>> loop, so better leave it as is.
>
> The compiler could in theory reduce to a single loop, but I've never
> seen one that does and would use the loop myself.

I changed the code[1] to use strlen() and strncmp() instead of some of
my hand-built functions while keeping the strlen() + '=' function.
Would there be any other changes anybody can see need to be made?  What
type of testing would be desired?  The regression tests I wrote provide
a good basic test.

In an attempt to make strlen() faster, I wrote a new strlen()[2] that
performs a trick to boost performance by searching by word then by byte
within a word to find the NUL byte.  It did not compare to the speed of
the built-in strlen() in GCC, but it is twice as fast as
lib/libc/string/strlen.c.  It was hard to really compare due to the
built-in code as well as what __pure does.  __pure seemed to make all
versions the same speed.  At some times, I really did not know for
certain which version (assembly, builtin, original, new) of strlen() I
was testing.  :)

Sean
   1. http://www.farley.org/freebsd/tmp/setenv-8/POSIX/sysenv-strlen.c
   2. http://www.farley.org/freebsd/tmp/strlen.c
-- 
sean-freebsd at farley.org