Hi, pg_itoa, pg_ltoa and pg_lltoa all have access to the length of the string that is produced in the function by way of the "len" variable. These functions don't have a great deal of use in core, but it seems that most callers do require the len but end up getting it via strlen(). It seems we could optimise this a little if we just had the functions return the length instead of making callers do the work themselves.
This allows us to speed up a few cases. int2vectorout() should be faster and int8out() becomes a bit faster if we get rid of the strdup() call and replace it with a palloc()/memcpy() call. The slight drawback that I can see from this is that on testing int4out() it gets slightly slower, which I assume is because I'm now returning the length, but there's no use for it in that function. create table bi (a bigint); insert into bi select generate_Series(1,10000000); vacuum freeze analyze bi; bench.sql = copy bi to '/dev/null'; BIGINT test drowley@amd3990x:~$ pgbench -n -f bench.sql -T 120 postgres Master: latency average = 1791.597 ms Patched: latency average = 1705.322 ms (95.184%) INT test create table i (a int); insert into i select generate_Series(1,10000000); vacuum freeze analyze i; bench.sql = copy i to '/dev/null'; drowley@amd3990x:~$ pgbench -n -f bench.sql -T 120 postgres Master: latency average = 1631.956 ms Patched: latency average = 1678.626 ms (102.859%) As you can see, this squeezes about 5% extra out of a copy of a 10 million row bigint table but costs us almost 3% on an equivalent int table. A likely workaround for that is moving the functions into the header file and making them static inline. It would be nice not to have to do that though. These tests were done on modern AMD hardware. I've not tested yet on anything intel based. I've copied in Andrew as I know he only recently rewrote these functions and Andres since he did mention this in [1]. I'm interested to know if that int4out regression exists on other hardware. David [1] https://www.postgresql.org/message-id/20190920051857.2fhnvhvx4qddd...@alap3.anarazel.de
return_strlen_num_in_numutils.patch
Description: Binary data