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 1g7lT1-0002FQ-I6 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Oct 2018 18:01:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g7lSx-0007mj-FX for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Oct 2018 18:01:43 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g7lSx-0007mc-52 for pgsql-hackers@lists.postgresql.org; Wed, 03 Oct 2018 18:01:43 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g7lSu-0007k4-3I for pgsql-hackers@lists.postgresql.org; Wed, 03 Oct 2018 18:01:41 +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 w93I1ZmN003317; Wed, 3 Oct 2018 14:01:35 -0400 From: Tom Lane To: Andres Freund cc: pgsql-hackers@lists.postgresql.org, Thomas Munro , Andrew Gierth , Alexander Kuzmenkov Subject: Re: Performance improvements for src/port/snprintf.c In-reply-to: <20181003174513.wxjxfj7eepytnlqa@alap3.anarazel.de> References: <20181003155207.b3lqmovuv2c5c4id@alap3.anarazel.de> <26510.1538582852@sss.pgh.pa.us> <20181003161454.ozeioucsimjg5g6m@alap3.anarazel.de> <27041.1538583733@sss.pgh.pa.us> <20181003163717.oycshpp2hnctvtfj@alap3.anarazel.de> <28321.1538585692@sss.pgh.pa.us> <20181003170043.thdyezozi343dkuc@alap3.anarazel.de> <2132.1538587869@sss.pgh.pa.us> <20181003173639.tncawup2nnkp7vbv@alap3.anarazel.de> <2435.1538588403@sss.pgh.pa.us> <20181003174513.wxjxfj7eepytnlqa@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Wed, 03 Oct 2018 10:45:13 -0700" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <3172.1538589495.0@sss.pgh.pa.us> Date: Wed, 03 Oct 2018 14:01:35 -0400 Message-ID: <3316.1538589695@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3172.1538589495.1@sss.pgh.pa.us> Andres Freund writes: > So when using pg's snprintf() to print a single floating point number > with precision, we get nearly a 10% boost. I just tested that using my little standalone testbed, and I failed to replicate the result. I do see that strfromd is slightly faster, but it's just a few percent measuring snprintf.c in isolation --- in the overall context of COPY, I don't see how you get to 10% net savings. So I continue to think there's something fishy about your test case. BTW, so far as I can tell on F28, strfromd isn't exposed without "-D__STDC_WANT_IEC_60559_BFP_EXT__", which seems fairly scary; what else does that affect? regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="hack-use-of-strfromd.patch"; charset="us-ascii" Content-ID: <3172.1538589495.2@sss.pgh.pa.us> Content-Description: hack-use-of-strfromd.patch Content-Transfer-Encoding: quoted-printable diff --git a/src/port/snprintf.c b/src/port/snprintf.c index b9b6add..f75369c 100644 --- a/src/port/snprintf.c +++ b/src/port/snprintf.c @@ -1137,17 +1137,19 @@ fmtfloat(double value, char type, int forcesign, i= nt leftjust, zeropadlen =3D precision - prec; fmt[0] =3D '%'; fmt[1] =3D '.'; - fmt[2] =3D '*'; - fmt[3] =3D type; - fmt[4] =3D '\0'; - vallen =3D sprintf(convert, fmt, prec, value); + fmt[2] =3D (prec / 100) + '0'; + fmt[3] =3D ((prec % 100) / 10) + '0'; + fmt[4] =3D (prec % 10) + '0'; + fmt[5] =3D type; + fmt[6] =3D '\0'; + vallen =3D strfromd(convert, sizeof(convert), fmt, value); } else { fmt[0] =3D '%'; fmt[1] =3D type; fmt[2] =3D '\0'; - vallen =3D sprintf(convert, fmt, value); + vallen =3D strfromd(convert, sizeof(convert), fmt, value); } if (vallen < 0) goto fail; ------- =_aaaaaaaaaa0--