Re: dll loading time performance
Frank-O schrieb:
On 14 f?v, 10:34, "Alf P. Steinbach" <al...@start.no> wrote:
* Frank-O:
I got a problem, I want to speed up the startup of my huge application
(100 dlls)
Reduce the number of DLLs drastically.
Consider splitting the single monlithic application into several programs.
For the rest, consider delay-loaded DLLs (directly supported by Visual C++).
the loading of one particular dll (gred.dll) takes about 10sec.
You could check the dependencies, but since you're going to redesign
this thing anyway (aren't you?) there's not really much point in that.
Ditto for basing the DLLs (assigning preferred load addresses).
one my
of my colleague suggested to load that dll in a background thread at
startup.
What's wrong with multithreading for that purpose ?
Before considerung solutions, you should analyse the problem.
The question is: Why does the DLL load so slow? Why do you think that multiple
threads would make loading faster?
When loading of a DLL takes a long time, it can be due to many reasons:
* The DLL is really huge, so the time is spent reading the hard disk.
* The DLL has a very complex DllMain that takes a long time to execute
* The DLL has many dependencies that need to be loaded as well.
* Windows needs to rebase the DLL
* The DllMain allocates a huge amount of memory so windows needs to re-arrange
its memory layout (trashing, paging)
There might be more reasons. But as long as the reason is not the busy CPU than
you won't gain much performance effect when loading the DLL in a separate
thread. All threads share the same hard disk, memory manager, process etc. And I
guess the main application still needs to wait until all DLLs have been loaded
before it can proceed.
What you actually can do is move the complete DLL loading funtion into a
separate thread. At least you can have the GUI responsive and the user gets the
feeling the application loads fast. You would still need to disable all commands
that rely on the not-yet-loaded DLLs.
Norbert