please wait
- Forum
- General C++ Programming
- Which is faster static or dynamic linkin
Which is faster static or dynamic linking?
Mar 30, 2010 at 2:29pm
Which is faster static or dynamic linking?
How much performance improvement can dynamic linking yields in comparison to static linking.
How much performance improvement can dynamic linking yields in comparison to static linking.
Last edited on Mar 30, 2010 at 2:29pm
Mar 30, 2010 at 4:59pm
I think the question is a bit wrong to be honest, because I don't think you can really compare the two for the following reason.
static linking = linking during compile time. (whole library included in .exe)
dynamic linking = linking during run time. (library not included in .exe but in separate .dll)
But if you really want to know I think dynamic linking would be slower, because it would need to search for the dll's to link to, every time you would run the program.
Dynamic link libraries aren't really used to improve performance though, the concept of using them is based more on reusability. For example, almost all windows' games use direct x. So instead of having the direct x library included in every .exe which would take up a lot of space. They just put it in one dll, and programs can link to it when they need it.
static linking = linking during compile time. (whole library included in .exe)
dynamic linking = linking during run time. (library not included in .exe but in separate .dll)
But if you really want to know I think dynamic linking would be slower, because it would need to search for the dll's to link to, every time you would run the program.
Dynamic link libraries aren't really used to improve performance though, the concept of using them is based more on reusability. For example, almost all windows' games use direct x. So instead of having the direct x library included in every .exe which would take up a lot of space. They just put it in one dll, and programs can link to it when they need it.
Last edited on Mar 30, 2010 at 5:06pm
Mar 31, 2010 at 12:53pm
Yes, it is an O(1) problem. The only overhead you have is to load the library, once, when your program first starts. (If you really know what you are doing, you can load during your program's execution, but if you know enough to do that then you understand how it impacts your runtime...)
Mar 31, 2010 at 1:16pm
Anyone got experience how using DLL's or static linking can change the link times of large projects? What is faster? And if DLL is faster to link, it is still faster to "link + additional costs for run" ?
The reason I ask: Some website I read recently was bragging about fast compile/link times for their projects. The author said, everything above 2 seconds is not good for incremental builds, as you want to do this all the time together with post-build unit testing.
Thing is.. even my super-small projects with like 3-4 projects (static libs) containing 20 source files each need around 2-3 seconds to link together. I do static linking. But I am kindof lazy to figure out how to get all this stuff to dynamic linking, so I thought I ask first ;)
Ciao, Imi.
The reason I ask: Some website I read recently was bragging about fast compile/link times for their projects. The author said, everything above 2 seconds is not good for incremental builds, as you want to do this all the time together with post-build unit testing.
Thing is.. even my super-small projects with like 3-4 projects (static libs) containing 20 source files each need around 2-3 seconds to link together. I do static linking. But I am kindof lazy to figure out how to get all this stuff to dynamic linking, so I thought I ask first ;)
Ciao, Imi.
Mar 31, 2010 at 2:30pm
> ...bragging about fast compile/link times for their projects.
(1) Build on ramdisk.
(2) Reduce the number of files in your library search path.
(1) Build on ramdisk.
(2) Reduce the number of files in your library search path.
Mar 31, 2010 at 2:35pm| (1) Build on ramdisk. (2) Reduce the number of files in your library search path. |
:-? ... :-| ... :-) ... :-D
Nice suggestions. Thank's choisum. I'll try that.
Ciao, Imi.
Apr 3, 2010 at 11:45am
Wait... we're talking about two different things.
Link time is part of the compilation process.
Load time is part of the execution process.
It doesn't matter if link time is a little slow (though we programmers would prefer it faster).
Load time matters to the end user.
I don't know how you are getting 2-3 seconds... but some (particularly older) C and C++ systems are known for being slow...
Link time is part of the compilation process.
Load time is part of the execution process.
It doesn't matter if link time is a little slow (though we programmers would prefer it faster).
Load time matters to the end user.
I don't know how you are getting 2-3 seconds... but some (particularly older) C and C++ systems are known for being slow...
Apr 7, 2010 at 7:28am
In my scenario, it would be the "link time of whole project + load time of unit test executable" that counts. The load time is not measurable fast for me (using static linking) but the link time was unbearable slow.
I did choisum's suggestions and voila: super-fast. :-).
(The cleanup of the library path actually did the trick. Using RAM disk didn't change anything at all.)
Ciao, Imi.
I did choisum's suggestions and voila: super-fast. :-).
(The cleanup of the library path actually did the trick. Using RAM disk didn't change anything at all.)
Ciao, Imi.
Topic archived. No new replies allowed.