Re: Performance improvements for src/port/snprintf.c
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>, pgsql-hackers@lists.postgresql.org
Date: 2018-09-27T02:05:20Z
Lists: pgsql-hackers
On 2018-09-26 21:44:41 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Reading around the interwebz lead me to look at ryu > > > https://dl.acm.org/citation.cfm?id=3192369 > > https://github.com/ulfjack/ryu/tree/46f4c5572121a6f1428749fe3e24132c3626c946 > > > That's an algorithm that always generates the minimally sized > > roundtrip-safe string output for a floating point number. That makes it > > insuitable for the innards of printf, but it very well could be > > interesting for e.g. float8out, especially when we currently specify a > > "too high" precision to guarantee round-trip safeity. > > Yeah, the whole business of round-trip safety is a bit worrisome. Seems like using a better algorithm also has the potential to make the output a bit smaller / more readable than what we currently produce. > If we change printf, and it produces different low-order digits > than before, will floats still round-trip correctly? I think we > have to ensure that they do. Yea, I think that's an absolutely hard requirement. It'd possibly be a good idea to add an assert that enforce that, although I'm not sure it's worth the portability issues around crappy system libcs that do randomly different things. > BTW, were you thinking of plugging in strfromd() inside snprintf.c, > or just invoking it directly from float[48]out? The latter would > presumably be cheaper, and it'd solve the most pressing performance > problem, if not every problem. I wasn't actually seriously suggesting we should use strfromd, but I guess one way to deal with this would be to add a wrapper routine that could directly be called from float[48]out *and* from fmtfloat(). Wonder if it'd be worthwhile to *not* pass that wrapper a format string, but instead pass the sprecision as an explicit argument. Would make the use in snprintf.c a bit more annoying (due to fFeEgG support), but probably considerably simpler and faster if we ever reimplement that ourself. Greetings, Andres Freund
Commits
-
Improve snprintf.c's handling of NaN, Infinity, and minus zero.
- 6eb3eb577d76 12.0 landed
-
Rationalize snprintf.c's handling of "ll" formats.
- 595a0eab7f42 12.0 landed
-
Provide fast path in snprintf.c for conversion specs that are just "%s".
- 6d842be6c118 12.0 landed
-
Make assorted performance improvements in snprintf.c.
- abd9ca377d66 12.0 landed
-
Set snprintf.c's maximum number of NL arguments to be 31.
- 625b38ea0e98 12.0 cited
-
Always use our own versions of *printf().
- 96bf88d52711 12.0 cited