>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
Tom> However, it seems like it should still be on the table to look at Tom> other code that just does sprintf's job faster (such as the stb Tom> code Alexander mentioned). The stb sprintf is indeed a lot faster for floats than other sprintfs, but (a) it's still quite a lot slower than Ryu (COPY of my test table is 4.2 seconds with stb, vs 2.7 seconds with Ryu), and (b) it also produces changes in the insignificant digits, so while (it claims) the values are still round-trip convertible, they are neither the shortest representation nor the exact representation. For example, consider 1.9, which is 0x3FFE666666666666: exact value: 1.899999999999999911182158029987476766109466552734375 accepted input range: min: 1.89999999999999980015985556747182272374629974365234375 max: 1.90000000000000002220446049250313080847263336181640625 exact value rounded to 18 SF: 1.89999999999999991 Ryu output: 1.9E0 STB (%*.18g) output: 1.89999999999999992 sprintf (%*.18g) output: 1.89999999999999991 So while STB's output is in the acceptable range, it's not the result of rounding the exact value to 18 digits (as sprintf does on my system at least) and nor is it the shortest. Testing a bunch of random values it usually seems to be off from the rounded exact result by +/- 1 in the last digit. -- Andrew (irc:RhodiumToad)