From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Subject: Re: Performance improvements for src/port/snprintf.c
Date: Wed, 03 Oct 2018 12:43:26 -0400
Message-ID: <27858.1538585006@sss.pgh.pa.us> (raw)
In-Reply-To: <20181003163246.r3cr6kxt3gsl5hfc@alap3.anarazel.de>
References: <14302.1538005507@sss.pgh.pa.us>
<20180926235821.zmpxqv66ob7v2ffi@alap3.anarazel.de>
<15882.1538007944@sss.pgh.pa.us>
<20180927004022.lfhffbj3roxzf5ca@alap3.anarazel.de>
<20180927005705.shbl3n5hq3t65n2j@alap3.anarazel.de>
<87r2hffwda.fsf@news-spur.riddles.org.uk>
<CAEepm=1-3AG2O25VNnLXsjCM3EHBLW=jyJtpp_AMGG6a-GRJZA@mail.gmail.com>
<6FEC34CD-B8C0-44E2-8D1F-2320568BDC78@anarazel.de>
<30551.1538517271@sss.pgh.pa.us>
<26193.1538582367@sss.pgh.pa.us>
<20181003163246.r3cr6kxt3gsl5hfc@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2018-10-03 11:59:27 -0400, Tom Lane wrote:
>> I experimented with adding an initial check for "format is exactly %s"
>> at the top of dopr(), and couldn't get excited about that. Instrumenting
>> things showed that the optimization fired in only 1.8% of the calls
>> during a run of our core regression tests. Now, that might not count
>> as a really representative workload, but it doesn't make me think that
>> the case is worth optimizing for us.
> Seems right. I also have a hard time to believe that any of those "%s"
> printfs are performance critical - we'd hopefully just have avoided the
> sprintf in that case.
Yup, that's probably a good chunk of the reason why there aren't very
many. But we *do* use %s a lot to assemble multiple strings or combine
them with fixed text, which is why the other form of the optimization
is useful.
>> But then it occurred to me that there's more than one way to skin this
>> cat. We could, for an even cheaper extra test, detect that any one
>> format specifier is just "%s", and use the same kind of fast-path
>> within the loop. With the same sort of instrumentation, I found that
>> a full 45% of the format specs executed in the core regression tests
>> are just %s. That makes me think that a patch along the lines of the
>> attached is a good win for our use-cases. Comparing to Fedora 28's
>> glibc, this gets us to
> Hm, especially if we special case the float->string conversions directly
> at the hot callsites, that seems reasonable. I kinda wish we could just
> easily move the format string processing to compile-time, but given
> translatability that won't be widely possible even if it were otherwise
> feasible.
Yeah, there's a mighty big pile of infrastructure that depends on the
way *printf works. I agree that one way or another we're going to be
special-casing float8out and float4out.
BTW, I poked around in the related glibc sources the other day, and
it seemed like they are doing some sort of quasi-compilation of format
strings. I couldn't figure out how they made it pay, though --- without
some way to avoid re-compiling the same format string over and over,
seems like it couldn't net out as a win. But if they are avoiding
that, I didn't find where.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, thomas.munro@enterprisedb.com, andrew@tao11.riddles.org.uk, a.kuzmenkov@postgrespro.ru
Subject: Re: Performance improvements for src/port/snprintf.c
In-Reply-To: <27858.1538585006@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox