This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Improve performance of strncpy
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Wilco Dijkstra <wdijkstr at arm dot com>
- Cc: azanella at linux dot vnet dot ibm dot com, libc-alpha at sourceware dot org
- Date: Thu, 27 Nov 2014 21:50:54 +0100
- Subject: Re: [PATCH] Improve performance of strncpy
- Authentication-results: sourceware.org; auth=none
- References: <001a01cfefa3$0fb21330$2f163990$ at com> <20141123165227 dot GA27543 at domone> <000001d00a77$3d6bdf10$b8439d30$ at com>
On Thu, Nov 27, 2014 at 07:20:43PM -0000, Wilco Dijkstra wrote:
> > OndÅej BÃlka wrote:
> > On Fri, Oct 24, 2014 at 04:56:23PM +0100, Wilco Dijkstra wrote:
> > > Ping (there was some further discussion but I don't see an OK for this patch)
> > >
> > Looks ok, any reason why not simplify it more to strnlen+memcpy+memset?
> Well that is possible too. I benchmarked this and it is 1.7x on x64, and 2x
> on AArch64 (compared to my patch). However it does seem to be mostly due to
> the large strings, small strings are slower as you can see below. I don't
> believe that bench-strncpy is a good benchmark as it only seems to test strings
> of 0.5x, 1.0x and 2.0x the buffer size (none of which would be common in the
> real world), do you happen to know a better strncpy benchmark?
Not yet, I tried to find use case but nothing on my computer calls it.
That is nice as strncpy function that should not be used at performance
sensitive code. A zero fill that standard requires is totally unnecesary
and even if you have good idea about buffer size you easily be 20%
faster by using strlen+memcpy+writing terminator.
A real problem is when you do estimate buffer well or do not carefully
read strncpy description. Then its easy to write code that is ten times
slower as strcpy copies ~64 byte string followed by zeroing remaining
4032 bytes of buffer.