Re: Performance improvements for src/port/snprintf.c

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>
Subject: Re: Performance improvements for src/port/snprintf.c
Date: 2018-10-03 16:37:17
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2018-10-03 12:22:13 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
> >> [ scratches head ... ] How would that work? Seems like it necessarily
> >> adds a strlen() call to whatever we'd be doing otherwise. palloc isn't
> >> going to be any faster just from asking it for slightly fewer bytes.
> >> I think there might be something wrong with your test scenario ...
> >> or there's more noise in the numbers than you thought.
> > I guess the difference is that we're more likely to find reusable chunks
> > in aset.c and/or need fewer OS allocations. As the memory is going to
> > be touched again very shortly afterwards, the cache effects probably are
> > neglegible.
> > The strlen definitely shows up in profiles, it just seems to save at
> > least as much as it costs.
> > Doesn't strike me as THAT odd?
> What it strikes me as is excessively dependent on one particular test
> scenario. I don't mind optimizations that are tradeoffs between
> well-understood costs, but this smells like handwaving that's going to
> lose as much or more often than winning, once it hits the real world.

I'm not particularly wedded to doing the allocation differently - I was
just mildly wondering if the increased size of the allocations could be
problematic. And that lead me to testing that. And reporting it. I
don't think the real-world test differences are that large in this
specific case, but whatever.

It seems the general "use strfromd if available" approach is generally
useful, even if we need to serialize the precision. Putting it into an
inline appears to be helpful, avoids some of the otherwise precision
related branches. Do you have any feelings about which header to put
the code in? I used common/string.h so far.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-10-03 16:43:26 Re: Performance improvements for src/port/snprintf.c
Previous Message Andres Freund 2018-10-03 16:32:46 Re: Performance improvements for src/port/snprintf.c