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

Hi,
On Monday 01 November 2010 10:15:01 Andres Freund wrote:
> On Monday 01 November 2010 04:04:51 Itagaki Takahiro wrote:
> > On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > While looking at binary COPY performance I forgot to add BINARY and was
> > > a bit shocked to see printf that high in the profile...
> > >
> > > A change from 9192.476ms 5309.928ms seems to be pretty good indication
> > > that a change in that area is waranted given integer columns are quite
> > > ubiquous...
> > > * I renamed pg_[il]toa to pg_s(16|32|64)toa - I found the names
> > > confusing. Not sure if its worth it.
> > Agreed, but how about pg_i(16|32|64)toa? 'i' might be more popular than
> > 's'. See also
> > http://msdn.microsoft.com/en-US/library/yakksftt(VS.100).aspx
> I find itoa not as clear about signedness as stoa, but if you insist, I
> dont feel strongly about it.
Let whover commits it decide...

> > * The buffer reordering seems a bit messy.
> > //have to reorder the string, but not 0byte.
> > I'd suggest to fill a fixed-size local buffer from right to left
> > and copy it to the actual output.
> Is a bit cleaner maybe, but I dont see much point in putting it into its
> own function... But again, I don't feel strongly.
Using a seperate buffer cost nearly 500ms... So I only changed the comments
there.

The only way I could think of to make it faster was to fill the buffer from the
end and then return a pointer to the starting point in the buffer. The speed
benefits are small (around 80ms) and it makes the interface more cumbersome...

Revised version attached - I will submit this to the next comittfest now.

Andres