Re: Performance improvements for src/port/snprintf.c
От | Andres Freund |
---|---|
Тема | Re: Performance improvements for src/port/snprintf.c |
Дата | |
Msg-id | 20181003174513.wxjxfj7eepytnlqa@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Performance improvements for src/port/snprintf.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Performance improvements for src/port/snprintf.c
|
Список | pgsql-hackers |
On 2018-10-03 13:40:03 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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.c: > 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: