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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers