Re: Performance improvements for src/port/snprintf.c - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Performance improvements for src/port/snprintf.c
Date
Msg-id 87o9c7ahjh.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Performance improvements for src/port/snprintf.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Performance improvements for src/port/snprintf.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 >> Ryu is so blazing fast that with it, COPY of a table with 2million
 >> rows of 12 random float8 columns (plus id) becomes FASTER in text
 >> mode than in binary mode (rather than ~5x slower):

 Tom> Oh yeah?  Where's the code for this?

Upstream code is at https://github.com/ulfjack/ryu

Most of that is benchmarking, java, and other stuff not interesting to
us; the guts are under ryu/ and are dual-licensed under Boost 1.0 (which
I think we can use, since the only difference from BSD seems to be a
permissive one) as well as Apache 2.0 (which AFAIK we can't use).

I attach the patch I've used for testing, which has these changes from
upstream Ryu:

  - added ryu_ prefix to entry point functions
  - changed some #include file locations
  - added #define NDEBUG since there are a bunch of plain C assert()s

but I didn't touch the formatting or style of the Ryu code so it's all
C99 and // comments and OTB etc.

For testing purposes what I did was to change float[48]out to use the
Ryu code iff extra_float_digits > 0. This isn't likely what a final
version should do, just a convenience flag. The regression tests for
float8 fail of course since Ryu's output format differs (it always
includes an exponent, but the code for that part can be tweaked without
touching the main algorithm).

-- 
Andrew (irc:RhodiumToad)


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Performance improvements for src/port/snprintf.c
Next
From: Tom Lane
Date:
Subject: Re: Performance improvements for src/port/snprintf.c