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] Improve performance of strncpy


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.


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