|
|
comp.unix.programmer |
> Before I spend awhile trying to implement a modular system using > The kind of use I need to use it for is fairly performance critical So I imagine you're worried about the use of the functions To a zeroth approximation, I'd imagine neither effect would The extreme (and maybe contrived) cases remain as a source -- Simon Connah wrote: No specifics about MacOSX or BSD, but are you truly
> Hi folks,
> 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)?
> (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.
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().
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.
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.
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.
Eric Sosman
esos...@ieee-dot-org.invalid