This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

Re: [PATCH 4/*] Generic string memchr and strnlen


On Fri, Jul 24, 2015 at 04:10:24PM +0100, Wilco Dijkstra wrote:
> Getting back to this, if you don't have an optimized strnlen then
> it is always better to try to use memchr (there are 14 optimized
> implementations of memchr but only 6 for strnlen).
> 
> So I'd suggest changing strnlen in an independent patch as:
> 
> __strnlen (const char *str, size_t n)
> {
>   char *ret = __memchr (str, 0, n); 
>   return ret ? ret - str : n;
> }
> 
> It also looks worthwhile to express strlen and rawmemchr as memchr
> so that you only need one highly optimized function rather than many.
> Deferring to more widely implemented optimized assembler functions
> should result in better performance than trying to optimize these
> functions in C.
> 
No, that is bad idea. Unless you inline strnlen or memchr then you add
extra call overhead.

That is unless you want to claim that you want to save size.

As for optimized implementations of strnlen vs memchr it isn't clear
that we will delete all of them as they are slower.

Also its wrong way to solve it, a architecture maintainer should add
optimized strnlen implementations, that quite easy when you have memchr
implementation, add few macros to initially add start and different end
handling.

Suggestion to express strlen as memchr would just cause regression. On
my system there happened 9535682 calls of strlen while memchr was called
just 11633 times and rawmemchr 1742 times.

Also purpose of strlen and rawmechr is to be faster than memchr. Again
these should be implemented by architecture maintainer by removing size
checks from memchr implementation.


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