On 04/15/2014 03:39 AM, Tom Lane wrote:
> I still wish we could get rid of this problem by fixing the Windows build
> recipes so that the PGDLLEXPORT marking wasn't needed. We proved to
> ourselves recently that getting rid of PGDLLIMPORT on global variables
> wouldn't work, but I'm not sure that the function end of it was really
> investigated.
My understanding is that we *can* drop PGDLLEXPORT on functions without
actively breaking anything. But we probably shouldn't.
If we omit PGDLLEXPORT, the linker of the DLL/executable that imports
the extern function will generate a thunk from the .LIB file for the
target DLL during linkage; this thunk within the DLL/EXE with the
undefined extern then jumps to the real address within the defining DLL/EXE.
Reference: http://msdn.microsoft.com/en-us/library/zw3za17w.aspx
So in other words, it makes calls across DLL boundaries less efficient
by adding a layer of indirection. (No idea how this works in the
presence of link time base address randomization either).
I actually think we should *add* a LIBPQEXPORT that handles this for
libpq, much like PGDLLEXPORT does for postgres(.exe). And in the
process, rename PGDLLEXPORT to POSTGRESEXPORT or PGSERVEREXPORT or
something.
PGDLLEXPORT is probably less important overall - it'll mainly impact
extensions (like hstore, intarray, etc) that call into the server.
I wonder if this thunking still really mattres with modern CPU
architecures' smart branch prediction, TLB caches, etc. I haven't found
much info on the real world impact.
It would probably be reasonable to add PGDLLEXPORT within postgres.exe
only on functions we've intentionally exposed for use by extensions,
where those functions are likely to get called a lot and don't have
bigget costs like disk I/O, network I/O, expensive memory allocations,
etc, that make call time overheads irrelevant.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services