This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Preparsing sprintf format strings


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]