4

I'm using the POSIX dlopen/dlsym API's to load dynamic libraries at runtime and then call functions from those libraries by name.

Is it a good idea, performance-wise, to store the result of dlsym somewhere? Or does dlsym do its own caching already and would adding another layer be useless or even detrimental? Functions could potentially be called many, many times, but I don't really have a way of knowing in advance which ones, or how often they will be called.

Thanks!

Wander Nauta
  • 18,832
  • 1
  • 45
  • 62
  • 3
    Premature optimization is the root of all evil. Don't do anything until you *see* dlsym causing problems. – thiton May 08 '12 at 14:03
  • I think you should remember the value, but it has nothing to do with performance. It just makes sense that setup code figures out the function pointers you need, and later the code just calls them. – ugoren May 08 '12 at 14:34
  • @ugoren: Sadly, I don't know in advance which functions will be used (I don't even know which libraries they will be coming from). – Wander Nauta May 08 '12 at 14:38

1 Answers1

4

The dlsym function does not do any caching. It is simply accessing the ELF symbol tables (using its hash table, which is not very well implemented).

I think you should avoid calling dlsym on the same name and library a lot of times (e.g. millions of times).

You might use lazy techniques: put e.g. the name & library used in your dlsym calls together (in some of your structure or class) with the dlsym-ed function pointer, and call dlsym only when that pointer is null.

You also might want to catch dlsym failure as quickly as possible.

FWIW, you can call dlopen and dlsym a lot of times. In particular, you can have many dozens of thousands of dlopen-ed shared libraries on Linux, as my manydl.c example demonstrates. But avoid dlclose-ing a library if you still have an active call frame for some dlsym-ed function inside. Actually, you might never call dlclose and your program would still work (with a slight process address space leak).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547