Hi, On 2018-10-03 12:22:13 -0400, Tom Lane wrote: > Andres Freund <and...@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.
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. Greetings, Andres Freund
