> Before I spend awhile trying to implement a modular system using > dlopen(), does anyone know roughly what kind of performance overhead > dlopen() creates on a Mac OS X system (or in fact any BSD based UNIX)?
> The kind of use I need to use it for is fairly performance critical > (mainly latency) and I would hate to spend ages getting a system up and > running only to find out that it is too slow to do what I want.
No specifics about MacOSX or BSD, but are you truly worried about dlopen()? You'll probably use dlopen() fewer than ten times in the course of an entire program, so it will have less total impact on your program's running time than, say, stat().
So I imagine you're worried about the use of the functions residing in the library to which dlopen() gives you access. There are two (potential) penalties I can think of: First, each call must be indirect through a function pointer variable rather than direct to an address known at link time, and second, it may be that the address-space shenanigans with which a particular system supports dynamic linking tend to punish MMU's and TLB's and the like.
To a zeroth approximation, I'd imagine neither effect would be significant except perhaps in extreme (and maybe contrived) cases. Consider that strlen() probably resides in a dynamic library, along with memset() and qsort() and atan2(). I can see no reason to worry more about mySharedLibraryFunction() than about any of these -- so I suggest you worry about none.
The extreme (and maybe contrived) cases remain as a source of concern. If you have reason to suspect that your use of a function might be particularly taxing, you could experiment: Write two versions of the same function with different names, one linked statically into your program and one resident in a shared library. Your program can then make a few gazillion calls on each and measure the elapsed time to assess the size of the penalty dynamic linkage might impose.
|
