|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>|
|Subject:||Re: Performance improvements for src/port/snprintf.c|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2018-10-03 11:59:27 -0400, Tom Lane wrote:
> I wrote:
> > ... However, I did add recent glibc (Fedora 28)
> > to the mix, and I was interested to discover that they seem to have
> > added a fast-path for format strings that are exactly "%s", just as
> > NetBSD did. I wonder if we should reconsider our position on doing
> > that. It'd be a simple enough addition...
> I experimented with adding an initial check for "format is exactly %s"
> at the top of dopr(), and couldn't get excited about that. Instrumenting
> things showed that the optimization fired in only 1.8% of the calls
> during a run of our core regression tests. Now, that might not count
> as a really representative workload, but it doesn't make me think that
> the case is worth optimizing for us.
Seems right. I also have a hard time to believe that any of those "%s"
printfs are performance critical - we'd hopefully just have avoided the
sprintf in that case.
> But then it occurred to me that there's more than one way to skin this
> cat. We could, for an even cheaper extra test, detect that any one
> format specifier is just "%s", and use the same kind of fast-path
> within the loop. With the same sort of instrumentation, I found that
> a full 45% of the format specs executed in the core regression tests
> are just %s. That makes me think that a patch along the lines of the
> attached is a good win for our use-cases. Comparing to Fedora 28's
> glibc, this gets us to
Hm, especially if we special case the float->string conversions directly
at the hot callsites, that seems reasonable. I kinda wish we could just
easily move the format string processing to compile-time, but given
translatability that won't be widely possible even if it were otherwise
|Next Message||Andres Freund||2018-10-03 16:37:17||Re: Performance improvements for src/port/snprintf.c|
|Previous Message||Arthur Zakirov||2018-10-03 16:24:28||Re: libpq host/hostaddr/conninfo inconsistencies|