|From:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>|
|Subject:||Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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.
|Next Message||Alex Hunsaker||2010-11-02 00:40:00||Re: why does plperl cache functions using just a bool for is_trigger|
|Previous Message||Hiroshi Inoue||2010-11-01 23:43:35||Re: Complier warnings on mingw gcc 4.5.0|