Is a statically linked executable faster than a dynamically linked executable?

Question

Since the dynamically linked libraries have to be resolved at run-time, are statically linked executables faster than dynamically linked executables?

Solution 1

Static linking produces a larger executable file than dynamic linking because it has to compile all of the library code directly into the executable. The benefit is a reduction in overhead from no longer having to call functions from a library, and anywhere from somewhat to noticeably faster load times.

A dynamically linked executable will be smaller because it places calls at runtime to shared code libraries. There are several benefits to this, but the ones important from a speed or optimization perspective are the reduction in the amount of disk space and memory consumed, and improved multitasking because of reduced total resource consumption (particularly in Windows).

So it's a tradeoff: there are arguments to be made why either one might be marginally faster. It would depend on a lot of different things, such as to what extent speed-critical routines in the program relied on calls to library functions. But the important point to emphasize in the above statement is that it might be marginally faster. The speed difference will be nearly imperceptible, and difficult to distinguish even from normal, expected fluctuations.

If you really care, benchmark it and see. But I advise this is a waste of time, and that there are more effective and more important ways to increase your application's speed. You will be much better off in the long run considering factors other than speed when making the "to dynamically link or to statically link" decision. For example, static linking may be worth considering if you need to make your application easier to deploy, particularly to diverse user environments. Or, dynamic linking may be a better option (particularly if those shared libraries are not your own) because your application will automatically reap the benefits of upgrades made to any of the shared libraries that it calls without having to lift a finger.

---

EDIT: Microsoft makes the specific recommendation that you prefer dynamic linking over static linking:

It is not recommended to redistribute C/C++ applications that statically link to Visual C++ libraries. It is often mistakenly assumed that by statically linking your program to Visual C++ libraries it is possible to significantly improve the performance of an application. However the impact on performance of dynamically loading Visual C++ libraries is insignificant in almost all cases. Furthermore, static linking does not allow for servicing the application and its dependent libraries by either the application's author or Microsoft. For example, consider an application that is statically linked to a particular library, running on a client computer with a new version of this library. The application still uses code from the previous version of this library, and does not benefit from library improvements, such as security enhancements. Authors of C/C++ applications are strongly advised to think through the servicing scenario before deciding to statically link to dependent libraries, and use dynamic linking whenever possible.

Solution 2

It depends on the state of your disk and whether or not the DLLs might be used in other processes. A cold start happens when your program and its DLLs were never loaded before. An EXE without DLLs has a faster cold start since only one file needs to be found. You would have to have a badly fragmented disk that's almost full to not have this case.

A DLL can start to pay off when it is already loaded in another process. Now the code pages of the DLL are simply shared, startup overhead is very low and memory usage is efficient.

A somewhat similar case is a warm start, a startup where the DLL is still available in the file system cache from a previous time it was used. The difference between a cold and a warm start can be quite significant on a sluggish disk. The one reason that everybody likes a SSD.

Comments

[weiweishuo]

Vote up. This might be more important from a practical point of view.