svn commit: r351700 - head/lib/libc/string

[Ed Maste]

On Wed, 25 Sep 2019 at 11:46, Bruce Evans <brde at optusnet.com.au> wrote:
>
> On Wed, 25 Sep 2019, Ed Maste wrote:
>
> > On Fri, 20 Sep 2019 at 08:14, Bruce Evans <brde at optusnet.com.au> wrote:
> >>
> >> Optimizing this function [memchr] is especially unimportant,
> >
> > Why?
>
> Because it is almost never used, and most of its uses are unimportant.
>
> It is used a whole 26 times in all of /usr/src/*bin:

Sure, but libc exists for the benefit of more than just the FreeBSD
base system. Open source software and proprietary products built on
FreeBSD make use of memchr and other string routines and have
performance concerns.

> But how do you know that long strings are most common?  For short strings,
> it is better to have low overhead.

Indeed, there is a trade-off. Some ad-hoc testing confirms the
original implementation is faster for byte strings of less than 8
bytes (as one would expect), and showed it slower above that.

> LONG_BIT is another bad way of encoding the word size.  On arches with
> correctly sized longs, long is twice as wide as either a machine register
> or the maximum memory access width.  So it is usually twice the word size
> if correct.

One can argue that all of our 64-bit archs have incorrectly sized
longs then, but I don't find that useful.  The compilers and machines
FreeBSD runs on have 64-bit longs on 64-bit processors.

> register_t is closer to being correct.

That makes sense, although not currently used for that purpose
anywhere in libc (or other libs) that I can see.