On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
> > * I find the ARRAY_ITER_VARS/ARRAY_ITER_NEXT macros rather ugly. I don't
> > buy the argument that turning them into functions will be slower. I'd
> > bet the contrary on common platforms.
> Perhaps; do you want to do some testing and see?
I've added new iterator functions using a on-stack state variable and
array_iter_setup/next functions pretty analogous to the macros. And then
converted arrayfuncs.c to use them.
Codesize before introducing inline functions:
assert:
text data bss dec hex filename
8142400 50562 295952 8488914 8187d2 src/backend/postgres
optimize:
text data bss dec hex filename
6892928 50022 295920 7238870 6e74d6 src/backend/postgres
After:
assert:
text data bss dec hex filename
8133040 50562 295952 8479554 816342 src/backend/postgres
optimize:
text data bss dec hex filename
6890256 50022 295920 7236198 6e6a66 src/backend/postgres
That's a small decrease.
I'm not sure what exactly to use as a performance benchmark
here. For now I chose
SELECT * FROM (SELECT ARRAY(SELECT generate_series(1, 10000))) d, generate_series(1, 1000) repeat(i);
that'll hit array_out, which uses iterators.
pgbench -P 10 -h /tmp -p 5440 postgres -n -f /tmp/bench.sql -c 4 -T 60
(I chose parallel because it'll show icache efficiency differences)
before, best of four:
tps = 4.921260 (including connections establishing)
after, best of four:
tps = 5.046437 (including connections establishing)
That's a relatively small difference. I'm not surprised, I'd not have
expected anything major.
Personally I think something roughly along those lines is both more
robust and easier to maintain. Even if possibly need to protect against
inlines not being available.
Similarly using inline funcs for AARR_NDIMS/HASNULL does not appear to
hamper performance and gets rid of the multiple evaluation risk.
These patches are obviously WIP. Especially with the iter stuff it's
possible that the concept could be extended a bit further.
Greetings,
Andres Freund