Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons

On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> BTW, while we're thinking about marginal improvements: instead of
> constructing the string backwards and then reversing it in-place,
> what about building it working backwards from the end of the buffer
> and then memmove'ing it down to the start of the buffer?
>
> I haven't tested this but it seems likely to be roughly a wash
> speed-wise.  The reason I find the idea attractive is that it will
> immediately expose any caller that is providing a buffer shorter
> than the required length, whereas now such callers will appear to
> work fine if they're only tested on small values.
>
> A small downside is that pg_itoa would then need its own implementation
> instead of just punting to pg_ltoa.

I think that might be more clever than is really warranted. I get
your point about buffer overrun, but I don't think it's that hard for
callers to do the right thing, so I'm inclined to think that's not
worth much in this case. Of course, if memmove() can be implemented
as a single assembler instruction or something, that might be
appealing from a speed standpoint, but otherwise I think we may as
well stick with this. There's less chance of needlessly touching an
extra cache line, less chance of being confused by leftover garbage in
memory after the end of the output string, and less duplicate code.

I had given some thought to whether it might make sense to try to
figure out how long the string will be before we actually start
generating it, so that we can just start in the exactly right space
and have to clean up afterward. But the obvious implementation seems
like it could be more expensive than just doing the copy.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company