This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

rawmemchr


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I noticed that the cygwin source code frequently uses strchr(p,0) to find
the trailing NUL of a string.  glibc documents that they special case this
condition to be noticeably faster than normal strchr, and a couple
instructions faster than the corresponding strlen(p)+p; however, the
current newlib implementation lacks this special case, and is somewhat
inefficient when compared to glibc's extension of rawmemchr(p,0).  Put
another way, the current newlib implementation of strchr performs two
checks for a NUL byte instead of one, making strchr almost twice as slow
as strlen at finding the ending NUL.  I'm considering a patch to newlib
that implements rawmemchr, then (if not optimizing for space) lets strchr
use it to optimize this particular case.  But this leads to my question -
how best to implement this without penalizing embedded systems, who do not
want a non-ANSI entry point?

I'm thinking the best approach might be a separate file, rawmemchr.c,
which always provides the entry point __rawmemchr, and additionally, if at
ELIX_LEVEL 4, provides the entry point rawmemchr as a thin wrapper around
__rawmemchr.  Then, in strchr.c, if not optimizing for space, call
__rawmemchr.  In string.h, just provide the declaration for rawmemchr
alongside other extension interfaces.  Cygwin, which does not optimize for
space, could export rawmemchr as an alias directly to __rawmemchr to avoid
the overhead of the thin wrapper, and would benefit from the faster
strchr(p,0).  Thoughts?

I also think newlib could use some additional optimizations - many of its
string algorithms only use a word-based search if the initial byte is
aligned, falling back to a byte-wise search of the ENTIRE string if the
first byte was not aligned (I saw this in at least strlen, strchr,
memchr...).  A much smarter algorithm is to process the first few bytes
until alignment is achieved, so that even unaligned long strings can
benefit from aligned searches in the middle of the string.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgzhrUACgkQ84KuGfSFAYBrtQCePsKv/wDdx3PNAHtkjT6WakHV
Wb4AoLSJhe/rhBLqKk5A9QadxtkH+LV1
=BkO0
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]