From: Folkert van Heusden <folkert@vanheusden.com>
To: Willy Tarreau <w@1wt.eu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: strncpy optimalisation? (lib/string.c)
Date: Sun, 10 Dec 2006 22:35:19 +0100 [thread overview]
Message-ID: <20061210213518.GD30197@vanheusden.com> (raw)
In-Reply-To: <20061210210614.GD24090@1wt.eu>
...
> > 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 ?
My patch was incorrect; it would only repeatingly copy the first
character from the source.
This one (tested in test-code seperate from kernel) works:
diff -uNrBbd lib/string.c string-new.c
--- lib/string.c 2006-11-04 02:33:58.000000000 +0100
+++ string-new.c 2006-12-10 22:34:39.000000000 +0100
@@ -97,9 +97,10 @@
char *tmp = dest;
while (count) {
- if ((*tmp = *src) != 0)
- src++;
+ if (unlikely((*tmp = *src) == 0x00))
+ break;
tmp++;
+ src++;
count--;
}
return dest;
The improvement in speed depends on the size of the source and
destination. Maybe i did something wrong but it seems that in all cases
the new version is faster.
Test can be found here:
http://www.vanheusden.com/misc/kernel-strncpy-opt-test.c
Signed-off by: Folkert van Heusden <folkert@vanheusden.com>
Folkert van Heusden
--
www.vanheusden.com/multitail - win een vlaai van multivlaai! zorg
ervoor dat multitail opgenomen wordt in Fedora Core, AIX, Solaris of
HP/UX en win een vlaai naar keuze
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
next prev parent reply other threads:[~2006-12-10 21:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-10 20:52 Folkert van Heusden
2006-12-10 21:06 ` Willy Tarreau
2006-12-10 21:35 ` Folkert van Heusden [this message]
2006-12-10 22:05 ` Mitchell Blank Jr
2006-12-10 21:49 ` Folkert van Heusden
2006-12-10 21:49 ` Mitchell Blank Jr
2006-12-10 21:39 ` Folkert van Heusden
2006-12-10 23:28 ` Bernd Petrovitsch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061210213518.GD30197@vanheusden.com \
--to=folkert@vanheusden.com \
--cc=linux-kernel@vger.kernel.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®