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

On Fri, Nov 19, 2010 at 4:16 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On Monday 15 November 2010 17:12:25 Robert Haas wrote:> I notice that int8out
> isn't terribly consistent with int2out and
>> int4out, in that it does an extra copy.   Maybe that's justified given
>> the greater potential memory wastage, but I'm not certain.  One
>> approach might be to pick some threshold value and allocate a buffer
>> in one of two sizes based on how large the value is relative to that
>> cutoff.  But that might also be a stupid idea, not sure.
> I removed the extra buffer - its actually a tiny bit faster without it  (I
> guess the allocation pattern is a bit nicer during copy as it will always take
> the same paths and eventually the same address).
> I couldn't measure any difference memory-usage wise.
>
> The code was that way before btw.

Yeah, I know. After further thought I decided not to commit this
part, because using 32 bytes when you only need 8 is sort of sucky.
I'm not sure if it matters in real life, but if it's only a tiny
speedup I guess I might as well play it safe.

>> It would speed things up for me if you or someone else could take a
>> quick pass over what remains here and fix the formatting and
>> whitespace to be consistent with our general project style, and make
>> the comment headers more consistent among the functions being
>> added/modified.
> I think I did most of those - the function comments in numutils weren't
> consistent before - now its consistent with the unchanged pg_atoi.
>
> Thanks for reviewing/applying the first part,

Sure thing. Thanks for taking time to do this - very nice speedup.
This part now committed, too.

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