Hi, On 2021-10-21 16:37:57 -0700, Andres Freund wrote: > On 2021-10-21 18:27:25 -0400, Tom Lane wrote: > > (a) the executable size increases by a few KB --- apparently, even > > the minimum subset of simplehash.h's functionality is code-wasteful. > > Hm. Surprised a bit by that. In an optimized build the difference is a > smaller, at least. > > optimized: > text data bss dec hex filename > 448066 7048 1368 456482 6f722 src/bin/pg_dump/pg_dump > 447530 7048 1496 456074 6f58a src/bin/pg_dump/pg_dump.orig > > debug: > text data bss dec hex filename > 516883 7024 1352 525259 803cb src/bin/pg_dump/pg_dump > 509819 7024 1480 518323 7e8b3 src/bin/pg_dump/pg_dump.orig > > The fact that optimization plays such a role makes me wonder if a good chunk > of the difference is the slightly more complicated find{Type,Func,...}ByOid() > functions.
It's not that. In a debug build a good chunk of it is due to a bunch of Assert()s. Another part is that trivial helper functions like SH_PREV() don't get inlined. The increase for an optimized build seems to boil down to pg_log_error() invocations. If I replace those with an exit(1), the resulting binaries are within 100 byte. If I prevent the compiler from inlining findObjectByCatalogId() in all the find*ByOid() routines, your version is smaller than master even without other changes. Greetings, Andres Freund