Up until now, I’ve only ever written and built static libraries, and so, I’m new to the shared library scene, or DLLs, as they are called on Windows.

From what I understand, the key feature of DLLs is that the library code is "loaded" and "unloaded" from the application as it makes calls into library. As such, my question is, does this dynamic loading and unloading (generally) make DLLs non-ideal for speed critical applications?

For example, consider this C++ snippet:

int x = 4;
lib_function(x);
non_lib_function();
My_Lib_Type foo(4, 3);

Assuming My_Lib_Type and lib_function() are defined in the DLL, would the application load the library to call lib_function(), unload after the call, and then load again to call the constructor for My_Lib_Type? If this is how it works, how fast is this switching process?

>Solution :

A DLL is typically loaded (and unloaded) only once by an application: either implicitly (if your executable is linked against it, via the corresponding export library) or explicitly (via calls to LoadLibrary() and FreeLibrary(), on Windows). It is not loaded each time one of its functions is called.

Once that DLL is loaded, its component functions and other exported units are accessed in much the same way as those defined in the executable module itself – the DLL is loaded into the process memory of the calling application.

So, no, there will be no noticeable speed degradation (or there shouldn’t be) when using a DLL over a statically-linked library.