Many programmers mistakenly think that a large DLL size will impact ASP.NET server-side performance. On the contrary, it is better to have a single large DLL than multiple smaller DLLs. In fact, the size of the DLL doesn’t matter. The cost of loading a large DLL is basically equal to loading a small DLL.
Some excerpts from an article at VBAccelerator.com:
"Base Addresses are covered in the MSDN Library in an article by Ruediger R. Asche, "Rebasing Win32 DLLs: The Whole Story" … Whilst the article is long and technical, the aim of it was to find out empirically the performance impact of re-basing a DLL when base addresses clash. … His other conclusions are interesting to VB coders though:"
* "All other things being equal, the size of the DLL does not matter; that is, the costs for loading a small DLL and a large DLL are pretty much equal. Thus, if possible, you should avoid writing a lot of small DLLs and instead write fewer large DLLs if load time is an issue for you. Note that this observation holds true over a very wide range of DLL sizes. When I ran the test on the huge binary DLL […] the load time did not differ very much from the load time for the small DLL that contains six pages total."
* "The single biggest factor that slows down the loading of DLLs is the location of the DLL. The documentation for LoadLibrary describes the algorithm that the operating system uses for locating the DLL image; a DLL located at the first search position (the current directory) loads in typically 20 percent or less of the time as the same DLL located deep down in the path loads. It is fairly obvious that the exact load time difference depends a lot on the length of the path, the efficiency of the underlying file system, and the number of files and directories that need to be searched."
* "Rebasing the [test] DLL incurs an overhead of about 600 percent on Windows NT and around 400 percent on Windows 95. Note, however, that this implies a great number of fixups (34,000 in the sample suite). For a typical DLL, the number is much smaller on the average; for example, in the debug version of MFC30D.DLL, which ships with Visual C++ version 2.x, there are about [..] 5 percent of the [..] fixups."
