Re: Performance improvements for src/port/snprintf.c
От | Andres Freund |
---|---|
Тема | Re: Performance improvements for src/port/snprintf.c |
Дата | |
Msg-id | 20180927020520.ublgc46h2sj73k47@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-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
В списке pgsql-hackers по дате отправления: