Dynamic linking costs two cycles
My blog has moved! Read it in the new location here.
It turns out that the overhead of dynamic linking on Linux amd64 is 2 CPU cycles per cross-module call. I usually take forever to get to the point in my writing, so I thought I would change this for once :-)
In MySQL, there has been a historical tendency to favour static linking, in ( Read more... )
It turns out that the overhead of dynamic linking on Linux amd64 is 2 CPU cycles per cross-module call. I usually take forever to get to the point in my writing, so I thought I would change this for once :-)
In MySQL, there has been a historical tendency to favour static linking, in ( Read more... )
Comments 3
Reply
"However, on modern systems there are also very serious drawbacks when using static linking"
P.S. please don't talk about packaging advantages -- it's bullshit.
Reply
One big issue is when you link library A statically, and also link library B
dynamically, and B itself uses A. Then you end up with parts of A from the
static linking of the program and other parts of A from the dynamic linking of
B. This will cause a lot of grief unless the two versions of A are exactly the
same.
If the program is _completely_ statically linked then this problem does not
occur, but that is becoming increasingly difficult to ensure.
Just doing a hostname lookup with glibc will cause dynamic loading of
different resolver libraries, which will crash if the static version of libc
is different from the dynamic one. MySQL/MariaDB, like many other larger
applications, support dynamic loading of plugins, which involves dynamic
linking.
Reply
Leave a comment