Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5K7s-00054e-6X for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Sep 2018 00:25:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g5K7q-0001Wt-Ha for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Sep 2018 00:25:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5K7q-0001Wm-Ai for pgsql-hackers@lists.postgresql.org; Thu, 27 Sep 2018 00:25:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5K7o-0000y6-6b for pgsql-hackers@lists.postgresql.org; Thu, 27 Sep 2018 00:25:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w8R0PiAI015883; Wed, 26 Sep 2018 20:25:44 -0400 From: Tom Lane To: Andres Freund cc: Alexander Kuzmenkov , pgsql-hackers@lists.postgresql.org Subject: Re: Performance improvements for src/port/snprintf.c In-reply-to: <20180926235821.zmpxqv66ob7v2ffi@alap3.anarazel.de> References: <11787.1534530779@sss.pgh.pa.us> <2238.1534716465@sss.pgh.pa.us> <15785.1536776055@sss.pgh.pa.us> <20180926220419.lorxpb564gakdjkz@alap3.anarazel.de> <20180926221814.el5nwmkez6zfmzbz@alap3.anarazel.de> <14302.1538005507@sss.pgh.pa.us> <20180926235821.zmpxqv66ob7v2ffi@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Wed, 26 Sep 2018 16:58:21 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15881.1538007944.1@sss.pgh.pa.us> Date: Wed, 26 Sep 2018 20:25:44 -0400 Message-ID: <15882.1538007944@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > On 2018-09-26 19:45:07 -0400, Tom Lane wrote: >> No, there are no additional layers that weren't there before --- >> snprintf.c's snprintf() slots in directly where the platform's did before. > Hm? What I mean is that we can't realistically be faster with the > current architecture, because for floating point we end up doing glibc > sprintf() in either case. Oh, you mean specifically for the float conversion case. I still say that I will *not* accept judging this code solely on the float case. The string and integer cases are at least as important if not more so. >> Interesting. strfromd() is a glibc-ism, and a fairly recent one at >> that (my RHEL6 box doesn't seem to have it). > It's C99 afaict. It's not in POSIX 2008, and I don't see it in my admittedly-draft copy of C99 either. But that's not real relevant -- I don't see much reason not to use it if we want a quick and dirty answer for the platforms that have it. If we had more ambition, we might consider stealing the float conversion logic out of the "stb" library that Alexander pointed to upthread. It says it's public domain, so there's no license impediment to borrowing some code ... regards, tom lane