On Tuesday 09 October 2007 20:48, Heikki Linnakangas wrote:
> The new linux code is slightly but not much faster than the old one
> (3.04s vs 3.16s),
Test on my machine (three runs)
$ time ./sprintf-linux
./sprintf-linux 10-70-110
user 0m2.018s
user 0m2.024s
user 0m1.997s
$ time ./sprintf-linux-new
./sprintf-linux-new 10-70-110
user 0m1.839s
user 0m1.825s
user 0m1.817s
Re Linux printf speed:
I measured 10% run time reduction in top caused by faster generation
of /proc data. This 10% includes all overhead of printf(), read(),
copying data from kernel to userspace, parsing it in top etc.
Microbenchmark in userspace (running number() in a tight loop)
gave x3 performance increase.
> but it does beat glibc (5.20s) by a wide margin.
> However, preparsing the format string in gcc still beats the linux
> version hands down (0.82s).
You preparse "%d-%d-%d"? Into what?
I am from "small is beautiful" camp. I don't like "code growth
for everyone for the benefit of 5% of code which really needs
that last bit of speed" policy.
I hate 80MB+ Oracle executables with passion.
What problems do you see with this:
sprintf(char *dst, const char *fmt, ...)
{
char *d;
char *p = strchr(fmt, '%');
/* Literal string? */
if (!p) {
d = stpcpy(dst, fmt);
return d - dst;
}
va_start(ap, fmt);
/* Copy leading literal prefix */
d = mempcpy(dst, fmt, p - fmt);
fmt = p;
/* Fast path for "...%s...%s...%s..." */
while (p[1] == 's') {
char *q = va_arg(ap, char*);
d = stpcpy(d, q);
fmt += 2; /* skip %s */
p = strchr(fmt, '%');
if (!p) {
d = stpcpy(d, fmt);
return d - dst;
}
d = mempcpy(d, fmt, p - fmt);
fmt = p;
}
...continue with original sprintf code...
}
It's small code increase, only in ONE place,
catches even cases where format is not constant.
--
vda
