Any difference in overhead between statically and dynamically linked libraries?

[Tamas Fehervari]

Hi,

I've been exploring ways to wrap a C library to use from Python, and found CFFI with the other usual suspects (in particular Cython, PyBind11, CPPYY and CTypes). I've found CFFI's approach very well thought out and easy to use, especially with support for opaque declarations. Thank you for designing such a good tool.

My question is if there is a difference in code "speed" (as in less calling overhead) between binding libraries in a static (.lib) or dynamic (.dll) way? I'm not referring to dlopen(), but in both cases I compile the CFFI code, and the only visible difference is that the .dll is required to import the compiled cffi wrapper if it's a dynamic binding. I'm using CFFI on Windows with CPython.

Basically, I was expecting the statically linked code to be faster, but there's basically no difference in calling times. On my system I'm seeing ~310 ns call times using CFFI in both cases (as opposed to ~110 ns when using a native Python function or ~120 ns with a Cython wrapper). I don't intend to start a "cython is faster" discussion here, my point is that statically or dynamically linked code seems to be the same and if that's as it should be?

I can include the (very short and simple) code I used for testing if necessary.

[Armin Rigo]

Hi Tamas,

On Sat, 18 Jan 2020 at 05:50, Tamas Fehervari
<igazsagos....@gmail.com> wrote:
> I've been exploring ways to wrap a C library to use from Python, and found CFFI with the other usual suspects (in particular Cython, PyBind11, CPPYY and CTypes). I've found CFFI's approach very well thought out and easy to use, especially with support for opaque declarations. Thank you for designing such a good tool.

Thank you!

> Basically, I was expecting the statically linked code to be faster, but there's basically no difference in calling times.

Yes, I don't expect the difference to be statistically significant.
The only difference is that in the static case, you have all the code
inside the same C extension module generated by CFFI, and in the
dynamic case you have a small wrapper C extension module and the real
code in a separate DLL. In both cases, a call from Python arrives in
some generated wrapper code that does things like argument parsing and
conversion from Python to C, and then there is a C call to the real
function. So we're really comparing the overhead of calling a C
function that is in the same DLL (but likely not the same .c file)
with the overhead of calling a C function from another DLL. It comes
with a small, one-time overhead of setting up more stuff for the DLL
case, but once that's done I expect the continuing overhead to be very
small or zero.


A bientôt,

Armin.

[Tamas Fehervari]

Armin, thank you for the explanation!