Subject: Re: Performance improvements for src/port/snprintf.c
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
References: <11787.1534530779@sss.pgh.pa.us> <2238.1534716465@sss.pgh.pa.us>
From: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Message-ID: <f5dd41da-911c-fd97-1b78-e0f8c0141897@postgrespro.ru>
Date: Fri, 7 Sep 2018 21:53:27 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <2238.1534716465@sss.pgh.pa.us>
Content-Type: multipart/alternative;
 boundary="------------1946F3DCF4ACDC986CAD92F9"
Content-Language: en-US
Precedence: bulk

This is a multi-part message in MIME format.
--------------1946F3DCF4ACDC986CAD92F9
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

I benchmarked this, using your testbed and comparing to libc sprintf 
(Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I know [1], all 
compiled with gcc 5.4.0 with -O2. I used bigger decimals in one of the 
formats, but otherwise they are the same as yours. Here is the table of 
conversion time relative to libc:

format                                 pg      stb
("%2$.*3$f %1$d\n", 42, 123.456, 2)    1.03    -
("%.*g", 15, 123.456)                  1.08    0.31
("%10d", 15)                           0.63    0.52
("%s", "012345678900123456789001234    2.06    6.20
("%d 012345678900123456789001234567    2.03    1.81
("%1$d 0123456789001234567890012345    1.34    -
("%d %d", 845879348, 994502893)        1.97    0.59

Surprisingly, our implementation is twice faster than libc on "%10d". 
Stb is faster than we are with floats, but it uses its own algorithm for 
that. It is also faster with decimals, probably because it uses a 
two-digit lookup table, not one-digit like we do. Unfortunately it 
doesn't support dollars.

1. https://github.com/nothings/stb/blob/master/stb_sprintf.h

-- 
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--------------1946F3DCF4ACDC986CAD92F9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>I benchmarked this, using your testbed and comparing to libc
      sprintf (Ubuntu GLIBC 2.27-0ubuntu3) and another implementation I
      know [1], all compiled with gcc 5.4.0 with -O2. I used bigger
      decimals in one of the formats, but otherwise they are the same as
      yours. Here is the table of conversion time relative to libc:<br>
    </p>
    <p>
      <style type="text/css"><!--td {border: 1px solid #ccc;}br {mso-data-placement:same-cell;}--></style></p>
    <p><tt>format                                 pg      stb</tt><tt><br>
      </tt><tt>("%2$.*3$f %1$d\n", 42, 123.456, 2)    1.03    -</tt><tt><br>
      </tt><tt>("%.*g", 15, 123.456)                  1.08    0.31</tt><tt><br>
      </tt><tt>("%10d", 15)                           0.63    0.52</tt><tt><br>
      </tt><tt>("%s", "012345678900123456789001234    2.06    6.20</tt><tt><br>
      </tt><tt>("%d 012345678900123456789001234567    2.03    1.81</tt><tt><br>
      </tt><tt>("%1$d 0123456789001234567890012345    1.34    -</tt><tt><br>
      </tt><tt>("%d %d", 845879348, 994502893)        1.97    0.59</tt></p>
    <p>Surprisingly, our implementation is twice faster than libc on
      "%10d". Stb is faster than we are with floats, but it uses its own
      algorithm for that. It is also faster with decimals, probably
      because it uses a two-digit lookup table, not one-digit like we
      do. Unfortunately it doesn't support dollars.</p>
    <p>1. <a class="moz-txt-link-freetext" href="https://github.com/nothings/stb/blob/master/stb_sprintf.h">https://github.com/nothings/stb/blob/master/stb_sprintf.h</a><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Alexander Kuzmenkov
Postgres Professional: <a class="moz-txt-link-freetext" href="http://www.postgrespro.com">http://www.postgrespro.com</a>
The Russian Postgres Company</pre>
  </body>
</html>

--------------1946F3DCF4ACDC986CAD92F9--