On 2018-09-26 19:45:07 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2018-09-26 15:04:20 -0700, Andres Freund wrote:
> >> I assume this partially is just the additional layers of function calls
> >> (psprintf, pvsnprintf, pg_vsnprintf, dopr) that are now done, in
> >> addition to pretty much the same work as before (i.e. sprintf("%.*f")).
>
> No, there are no additional layers that weren't there before ---
> snprintf.c's snprintf() slots in directly where the platform's did before.
Hm? What I mean is that we can't realistically be faster with the
current architecture, because for floating point we end up doing glibc
sprintf() in either case. And after the unconditional replacement,
we're doing a bunch of *additional* work (at the very least we're
parsing the format string twice).
> Well, ok, dopr() wasn't there before, but I trust you're not claiming
> that glibc's implementation of snprintf() is totally flat either.
I don't even think it's all that fast...
> > I'm *NOT* proposing that as the actual solution, but as a datapoint, it
> > might be interesting that hardcoding the precision and thus allowing use
> > ofusing strfromd() instead of sprintf yields a *better* runtime than
> > master.
>
> Interesting. strfromd() is a glibc-ism, and a fairly recent one at
> that (my RHEL6 box doesn't seem to have it). But we could use it where
> available. And it doesn't seem unreasonable to have a fast path for
> the specific precision value(s) that float4/8out will actually use.
It's C99 afaict. What I did for my quick hack is to just hack the
precision as characters into the format that dopr() uses...
Greetings,
Andres Freund