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

From Tom Lane
Subject Re: Performance improvements for src/port/snprintf.c
Date
Msg-id 31292.1538759432@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance improvements for src/port/snprintf.c  (Andres Freund <andres@anarazel.de>)
Responses Re: Performance improvements for src/port/snprintf.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-10-05 11:54:59 -0400, Tom Lane wrote:
>> I really think that what we ought to do is apply the float[48]out hack
>> I showed in <30551.1538517271@sss.pgh.pa.us> and call it good, at least
>> till such time as somebody wants to propose a full-on reimplementation of
>> float output.  I don't want to buy back into having platform dependencies
>> in this area after having just expended a lot of sweat to get rid of them.

> I'm not convinced. Because of some hypothetical platform that may
> introduce strfromd() in a broken/slower manner, but where sprintf() is
> correct, we should not do the minimal work to alleviate an actual
> performance bottleneck in a trivial manner on linux? Our most widely
> used platform?  If we find a platform where it's borked, we could just
> add a small hack into their platform template file.

If it were a significant performance improvement, I'd be okay with that
conclusion, but my measurements say that it's not.  The extra complication
is not free, and in my judgement it's not worth it.

We certainly do need to buy back the performance we lost in float[48]out,
but the hack I suggested does so --- on all platforms, not only Linux.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: SCRAM with channel binding downgrade attack
Next
From: Andres Freund
Date:
Subject: Re: Skylake-S warning