[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061210210614.GD24090@1wt.eu>
Date: Sun, 10 Dec 2006 22:06:14 +0100
From: Willy Tarreau <w@....eu>
To: Folkert van Heusden <folkert@...heusden.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: strncpy optimalisation? (lib/string.c)
On Sun, Dec 10, 2006 at 09:52:30PM +0100, Folkert van Heusden wrote:
> Hi,
>
> In lib/string.c we have:
>
> char *strncpy(char *dest, const char *src, size_t count)
> {
> char *tmp = dest;
>
> while (count) {
> if ((*tmp = *src) != 0)
> src++;
> tmp++;
> count--;
> }
> return dest;
> }
>
> now I wonder isn't this ineffecient when strlen(src) < count? It would
> then, if I'm correct, iterate count-strlen(src) times doing useless
> increment/decrement. And since there are aprox. 580 instances in the
> 2.6.18.2 source, maybe some efficency can be won here.
> Wouldn't it be better to do:
> if ((*tmp = *src) == 0x00)
> break;
>
> So that would be:
> --- lib/string.c 2006-11-04 02:33:58.000000000 +0100
> +++ string-new.c 2006-12-10 21:50:05.000000000 +0100
> @@ -97,8 +97,8 @@
> char *tmp = dest;
>
> while (count) {
> - if ((*tmp = *src) != 0)
> - src++;
> + if ((*tmp = *src) == 0x00)
> + break;
> tmp++;
> count--;
> }
While your code is faster, it does not do exactly the same.
Original code completely pads the destination with zeroes,
while yours only adds the last zero. Your code does what
strncpy() is said to do, but maybe there's a particular
reason for it to behave differently in the kernel (helping
during debugging, or filling specific structs).
Just out of curiosity, have you tried to do a general
benchmark to check if original code eats much CPU ?
Regards,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists