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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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 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.

Fair enough --- it was just a passing thought.

> 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.

Yeah. You certainly don't want to do the division sequence twice,
and a log() call wouldn't be cheap either, and there don't seem to
be many other alternatives. If we were going to get picky about
avoiding the reverse step, I'd go with Andres' idea of changing
the API to pass back an address instead of guaranteeing that the
result begins at the start of the buffer. But I think that's much
more complicated for callers than it's worth.

regards, tom lane