This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH] Improve performance of strncpy
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: "'Rich Felker'" <dalias at libc dot org>, "Florian Weimer" <fweimer at redhat dot com>
- Cc: <azanella at linux dot vnet dot ibm dot com>, <libc-alpha at sourceware dot org>
- Date: Thu, 11 Sep 2014 20:37:17 +0100
- Subject: RE: [PATCH] Improve performance of strncpy
- Authentication-results: sourceware.org; auth=none
- References: <001301cfcd0a$f0b62670$d2227350$ at com> <54108BB0 dot 90902 at redhat dot com> <20140910180144 dot GK23797 at brightrain dot aerifal dot cx>
> Rich Felker wrote:
> On Wed, Sep 10, 2014 at 07:34:40PM +0200, Florian Weimer wrote:
> > On 09/10/2014 05:21 PM, Wilco Dijkstra wrote:
> > >Yes, you're right, I timed it and there is actually little difference, while
> > >the code is now even simpler. New version below (not attaching results in bad
> > >characters due to various mail servers changing line endings).
> > >
> > >OK for commit?
> >
> > I think you could simplify it down to strnlen, memcpy, and memset.
>
> I don't think that's an improvement, at least not in the general case.
> It involves iterating twice over the source string, which for long
> strings could mean blowing the whole cache twice and fetching from
> main memory twice. There's a good reason that string operations are
> usually implemented to perform the copy and length computation
> together in a single pass.
I did a quick experiment with strcpy as it's simpler. Replacing it
with memcpy (d, s, strlen (s) + 1) is 3 times faster even on strings
of 16Mbytes! Perhaps more surprisingly, it has similar performance on
these huge strings as an optimized strcpy.
So the results are pretty clear, if you don't have a super optimized
strcpy, then strlen+memcpy is the best way to do it.
Wilco