Skip site navigation (1) Skip section navigation (2)

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

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Subject: Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons
Date: 2010-11-02 00:37:43
Message-ID: 201011020137.43501.andres@anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
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

Attachment: Implement-custom-int-248-string-conversion-routines-V2.patch
Description: text/x-patch (9.6 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Alex HunsakerDate: 2010-11-02 00:40:00
Subject: Re: why does plperl cache functions using just a bool for is_trigger
Previous:From: Hiroshi InoueDate: 2010-11-01 23:43:35
Subject: Re: Complier warnings on mingw gcc 4.5.0

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group