Em ter., 9 de jun. de 2020 às 07:55, David Rowley <dgrowleyml@gmail.com> escreveu:
On Tue, 9 Jun 2020 at 22:08, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote: > > >>>>> "David" == David Rowley <dgrowleyml@gmail.com> writes: > > David> This allows us to speed up a few cases. int2vectorout() should > David> be faster and int8out() becomes a bit faster if we get rid of > David> the strdup() call and replace it with a palloc()/memcpy() call. > > What about removing the memcpy entirely? I don't think we save anything > much useful here by pallocing the exact length, rather than doing what > int4out does and palloc a fixed size and convert the int directly into > it.
On looking back through git blame, it seems int2out and int4out have been that way since at least 1996, before int8.c existed. int8out has been doing it since fa838876e9f -- Include 8-byte integer type. dated 1998. Quite likely the larger than required palloc size back then was more of a concern. So perhaps you're right about just doing it that way instead. With that and the ints I tested with, the int8 performance should be about aligned to int4 performance.
> For pg_ltoa, etc., I don't like adding the extra call to pg_ultoa_n - at > least on my clang, that results in two copies of pg_ultoa_n inlined. > How about doing it like, > > int > pg_lltoa(int64 value, char *a) > { > int len = 0; > uint64 uvalue = value; > > if (value < 0) > { > uvalue = (uint64) 0 - uvalue; > a[len++] = '-'; > } > len += pg_ulltoa_n(uvalue, a + len); > a[len] = '\0'; > return len; > }
Written like that, wouldn't it get better?
int pg_lltoa(int64 value, char *a) { if (value < 0) { int len = 0; uint64 uvalue = (uint64) 0 - uvalue;
a[len++] = '-'; len += pg_ulltoa_n(uvalue, a + len); a[len] = '\0'; return len; } else return pg_ulltoa_n(value, a); }
