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

On September 26, 2018 9:04:08 PM PDT, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>On Thu, Sep 27, 2018 at 3:55 PM Andrew Gierth
><andrew(at)tao11(dot)riddles(dot)org(dot)uk> wrote:
>> >>>>> "Andres" == Andres Freund <andres(at)anarazel(dot)de> writes:
>> Andres> Hm, stb's results just for floating point isn't bad. The
>above
>> Andres> numbers were for %f %f. But as the minimal usage would be
>about
>> Andres> the internal usage of dopr(), here's comparing %.*f:
>>
>> Andres> snprintf time = 1324.87 ms total, 0.000264975 ms per
>iteration
>> Andres> pg time = 1434.57 ms total, 0.000286915 ms per iteration
>> Andres> stbsp time = 552.14 ms total, 0.000110428 ms per iteration
>>
>> Hmm. We had a case recently on IRC where the performance of float8out
>> turned out to be the major bottleneck: a table of about 2.7 million
>rows
>> and ~70 float columns showed an overhead of ~66 seconds for doing
>COPY
>> as opposed to COPY BINARY (the actual problem report was that doing
>> "select * from table" from R was taking a minute+ longer than
>expected,
>> we got comparative timings for COPY just to narrow down causes).
>>
>> That translates to approx. 0.00035 ms overhead (i.e. time(float8out)
>-
>> time(float8send)) per conversion (Linux server, hardware unknown).
>>
>> That 66 seconds was the difference between 18s and 1m24s, so it
>wasn't a
>> small factor but totally dominated the query time.
>
>For perfect and cheap round trip to ASCII, not for human consumption,
>I wonder about the hexadecimal binary float literal format from C99
>(and showing up in other places too).

I'm not quite sure how we realistically would migrate to that though. Clients and their users won't understand it, and the more knowledgeable ones will already use the binary protocol.

Answers
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.