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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Performance improvements for src/port/snprintf.c
Дата
Msg-id 17058.1538012681@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Performance improvements for src/port/snprintf.c  (Andres Freund <andres@anarazel.de>)
Ответы Re: Performance improvements for src/port/snprintf.c  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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.
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.  If we just use strfromd(), then it's
libc's problem if the results change ... but if we stick in some
code we got from elsewhere, it's our problem.

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.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Performance improvements for src/port/snprintf.c
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Performance improvements for src/port/snprintf.c