Re: Performance improvements for src/port/snprintf.c

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
Date: 2018-10-03 17:45:13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2018-10-03 13:40:03 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-10-03 13:31:09 -0400, Tom Lane wrote:
> >> I do not see the point of messing with snprintf.c here. I doubt that
> >> strfromd is faster than the existing sprintf call (because the latter
> >> can use ".*" instead of serializing and deserializing the precision).
> > I'm confused, the numbers I posted clearly show that it's faster?
> Those were in the context of whether float8out went through snprintf.c
> or directly to strfromd, no?

I measured both, changing float8out directly, and just adapting

> snprintf using sprintf via pg_double_to_string:
> 16195.787
> snprintf using strfromd via pg_double_to_string:
> 14856.974 ms
> float8out using sprintf via pg_double_to_string:
> 16176.169
> float8out using strfromd via pg_double_to_string:
> 13532.698

So when using pg's snprintf() to print a single floating point number
with precision, we get nearly a 10% boost. The win unsurprisingly is
bigger when not going through snprintf.c.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-10-03 17:51:38 Re: Performance improvements for src/port/snprintf.c
Previous Message Tom Lane 2018-10-03 17:40:03 Re: Performance improvements for src/port/snprintf.c