Messages in this thread | | | Date | Mon, 11 Dec 2006 00:13:05 +0100 | From | Adrian Bunk <> | Subject | Re: optimalisation for strlcpy (lib/string.c) |
| |
On Sun, Dec 10, 2006 at 10:23:51PM +0100, Folkert van Heusden wrote: > Hi, > > Like the other patch (by that other person), I think it is faster to not > do a strlen first. >... > --- lib/string.c 2006-11-04 02:33:58.000000000 +0100 > +++ string-new.c 2006-12-10 22:22:08.000000000 +0100 > @@ -121,14 +121,24 @@ > */ > size_t strlcpy(char *dest, const char *src, size_t size) > { > - size_t ret = strlen(src); > + char *tmp = dest; > > - if (size) { > - size_t len = (ret >= size) ? size - 1 : ret; > - memcpy(dest, src, len); > - dest[len] = '\0'; > + for(;;) > + { > + *dest = *src; > + if (!*src) > + break; > + > + if (--size == 0) > + break; > + > + dest++; > + src++; > } > - return ret; > + > + *dest = 0x00; > + > + return dest - tmp; >...
Two bugs in your code: - you copy a maximum of size bytes _plus_ \0 - size == 0 is no longer handled correctly
> I've tested the speed difference with this: > http://www.vanheusden.com/misc/kernel-strlcpy-opt-test.c > and the speed difference is quite a bit on a P4: 28% faster. >...
My Athlon says: org: 2.400000 new: 6.710000
IOW, your version is much slower.
But the main question is actually: Does the performance of this function matter anywhere inside the kernel? Is strlcpy() used in any fast path? If not, there's no point in trying to optimize it.
> Folkert van Heusden
cu Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |