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] Use strlen when searching for a nul char


On Wed, 7 Oct 2015, pinskia@gmail.com wrote:

> > On Oct 7, 2015, at 7:30 AM, Wilco Dijkstra <wdijkstr@arm.com> wrote:
> > 
> > Expand strchr (s, '\0') in C/C++ to use strlen. This is faster on most 
> > targets as strlen is a simpler function. Passes GLIBC tests. I'm 
> > planning to do the same for strrchr, strchrnul and rawmemchr in future 
> > patches as people frequently use all of these to find the end of a 
> > string.
> > 
> > OK for commit?
> 
> Shouldn't this also be an optimization inside gcc if not already?

I agree; I'd rather discourage the addition of such optimizations as 
inlines in glibc unless they depend on information that's inherently not 
available to GCC (e.g. properties of architecture-specific function 
implementations in glibc).  As I said before in 
<https://sourceware.org/ml/libc-alpha/2015-06/msg00146.html> the aim 
should be to make the GNU system as a whole as good as possible.

(And please accompany performance claims such as "faster on most targets" 
with figures from the benchtests or a reason it's hard to produce such 
figures.  In this case I think the transformation could be justified for 
GCC as something architecture-independent without specific performance 
claims - strlen being inherently simpler because it only ever has to 
search for 0 bytes, so it should never be asymptotically slower than the 
alternative and may be faster.)

-- 
Joseph S. Myers
joseph@codesourcery.com


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