Date: Sat, 3 Apr 2004 01:00:12 -0800 From: David Schultz <das@FreeBSD.ORG> To: Valentin Nechayev <netch@ivb.nn.kiev.ua> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: gnu/62782: strlcpy performance problem Message-ID: <20040403090012.GA18694@VARK.homeunix.com> In-Reply-To: <200403271940.i2RJeBgg052032@freefall.freebsd.org> References: <200403271940.i2RJeBgg052032@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 27, 2004, Valentin Nechayev wrote: > The following reply was made to PR gnu/62782; it has been noted by GNATS. > > From: Valentin Nechayev <netch@ivb.nn.kiev.ua> > To: chc <chc@mail2000.com.tw> > Cc: freebsd-gnats-submit@freebsd.org > Subject: Re: gnu/62782: strlcpy performance problem > Date: Sat, 27 Mar 2004 21:26:10 +0200 > > Fri, Feb 13, 2004 at 02:30:21, chc (chc) wrote about "gnu/62782: strlcpy performance problem": > > c> while (*s++); /* performance problem when src is mmap pointer */ > c> Mmap a big file which is above 500M and use strlcpy. I found it was very slow. > > As mapping is on per-page basis, any implementation of per-char scanning > (as required by C-styled string copy) will be much faster than page fault > interrupt. So your problem isn't strlcpy slowness, but bad program design: > you should not use nul-terminated strings for this task. > > PR is already closed, but I want add my $0.05 to clarify that it isn't > one function problem, but conceptual problem (and strncpy() can't fix it, > but can only aggravate). Redesign your program. Not quite. The problem is that the strlcpy() interface is defined to return the total length of the source string regardless of the amount actually copied. Therefore, unlike strncpy(), strlcpy() must scan until it reaches a terminating null. The line the original submitter complained about implements this functionality.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040403090012.GA18694>