5

I know that there's more overhead to calling a function in a DSO due to the double jump. Is there more overhead in calling a function in a separate compilation unit compared with calling one in the same compilation unit (assuming it's not inlined in both cases)?

Ross Lagerwall
  • 93
  • 6

2 Answers2

5

Generally speaking, they will be the same, not countin inlining or other global optimization oportunities. But there may be subtle differences depending on the architecture.

For example, in Linux/Unix, the issue is not between functions of different CU, but whether the function you are calling has external linkage or not:

void foo() {}
void bar()
{ foo(); }

Or:

static void foo() {}
void bar()
{ foo(); }

If this code is compiled into a shared object (but not into an executable!), then the external foo() might be overriden by another shared object (via LD_LIBRARY_PRELOAD for example), but the static one cannot. Thus, the call to external functions inside shared object, even from the same CU, must be done using a relocatable jump.

In Windows, however, there is no such thing as LD_LIBRARY_PRELOAD, so there is no such difference.

rodrigo
  • 94,151
  • 12
  • 143
  • 190
  • In a library you can sometimes improve this if you change the visibility of the symbol to be limited to the library. On gcc-compatible compilers this can be done by adding `__attribute__((visibility ("hidden")))` to the function prototype. This doesn't help on all operating systems and architectures, but it can sometimes improve things and doesn't hurt. – Art Jun 10 '14 at 08:59
  • @Art: Right! My preference is to compile with `-fvisibility=hidden` and then add `__attribute__((visibility("default"))` only to the symbols to be exported. – rodrigo Jun 10 '14 at 09:29
  • I see there's a linker option, -Bsymbolic, which makes references within a shared library bind to the symbols within that library. I suppose this way you don't have to change the visibility if you don't want to. – Ross Lagerwall Jun 10 '14 at 17:47
  • @RossLagerwall: Oh, I didn't know that. I've just tried it, and it looks like it does exactly what you say (I still like the `-fvisibility=hidden`, but for other reasons). – rodrigo Jun 10 '14 at 18:00
  • @RossLagerwall: yes, you could even mark symbols as local to the library: http://stackoverflow.com/a/6540059/371250 – ninjalj Jun 12 '14 at 11:04
0

The only possible overhead I see is with variable-length jump macros, which might always have the maximum length when jumping across compilation units (unless the linker optimizes that).

Medinoc
  • 6,577
  • 20
  • 42