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

Andres Freund <andres@anarazel.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.

            regards, tom lane