Improve application "cold" load time

Started by
18 comments, last by Yalpe 17 years, 11 months ago
Hey, I'm an intern in a corp and I have to figure out how to optimize the boot time of their image generator. I've already reduced it by 75% on a warm boot (ie.: boot the application, close it when its initialized then fire it up again). It seems that windows does a lot of caching in the background because it now takes 10 seconds to fire up under warm boot and still over 30s under cold boot. The real problem comes from how the projet is layed out. There is over 190 projets that compile into dlls. We have to keep them that way because the application is distributed (runs on many cpus). So is there a way to improve DLL load time for cold boots?
Advertisement
I doubt it. As you said, Windows will keep DLLs around in memory after they've been released by other modules, in case they get re-used. There's a registry value called AlwaysUnloadDll or something that you can set to force DLLs to always unload.
The only way I can think of would be to get Windows to touch the DLLs, by writing a program that just loads the DLLs, frees them, then exits.
Of course theres always a load screen, it doesn't speed up load times, but is better than staring at nothing. Just a simple startup window with a progress bar that progresses a step per dll or whatnot. But if you have a lot of DLLs to load, its going to take some time. The only other option, as evil mentioned, is having a second 'quicklaunch' app that loads the DLLs and then unloads them on windows startup. I know OpenOffice has a quicklaunche (and I ~think~ AOL had one too).
"Mommy, where do microprocessors come from?"
Thanks for the fast replies,

I don't know if it would work to have a loader. I'm not really good at distributed computing yet. Locally it would probably help but on the real simulators I doubt it. Btw, I tried to disable the registry key but there was still a great impact on performance on warm boot. Weird stuff. A load screen isn't really desireable because we only the devs uses the UI's since it is an image generator. Didn't adobe get a loader too in reader 7.0?.
Just having the modules in DLLs surely won't help anything even if used on multiple CPUs... or is there something you forgot to say?

Anyways, DLL loading takes a lot of time - when I read the headline I thought I'd step in and recommend minimizing the dependency of DLLs...

If it's at all possible (it should be unless you forgot to tell us something), link statically for faster start up speed.
The only other way to do it is dynamically load functions as you need them. Typically I wrap DLL calls inside of a class. I have the dll function pointers as private members, the public member functions that basically checks to see if the function is loaded, and if it isn't -- then load it, and finally call the function. That way If I had 10,000 functions, it'l only load them as I use them. Just an idea.
"Mommy, where do microprocessors come from?"
Most of the dlls are loaded via LoadLibrary. I'm not sure if I'm right (as I said I'm no pro in distributed computing) but I assumed you would need DLLs to spread the application on a cluster of machines. Its not only multiple CPUs into 1 PC.
Just found this article while browsing for something entirely unrelated. Only skimmed it quickly, but it might be useful to you:
Optimizing DLL Load Time Performance
I think the impression we are getting is that the DLLs are simply stored on other PCs, and loaded into this single app.. which is defintaly not distributed processing.. Then again, I know close to nothing about one app being ran on multiple PCs (with single multy-cpu machines, its done via threading iirc).
"Mommy, where do microprocessors come from?"
Have you tried rebasing your dll's?? We found that it helped increase the load tiem of Corel Draw.

Cheers
Chris
CheersChris

This topic is closed to new replies.

Advertisement