views:

261

answers:

7

Recently, my boss asked me to improve the launch speed of our application, the AP was written with C++. The AP is a little big, it used 200+ dll, Windows needs long time to enter the main() function. I tried these two ways, but still can't make our boss happy. 1. delay load dll http://msdn.microsoft.com/en-us/library/yx9zd12s(VS.80).aspx 2. use EDITBIN to to modify EXE http://msdn.microsoft.com/en-us/library/xd3shwhf(VS.80).aspx

Are there other ways to improve it? Thanks in advance.

+4  A: 

Jeez! Reduce that DLL count!

Of course, if you're gonna load 200 DLLs on startup, it's gonna incur heaps of hard page faults, and take forever to boot (like 3ds max).

Rethink your DLL strategy. Combine many small DLLs into larger ones. I seriously doubt you need 200+.

And watch Raymond Chen's Five Things Every Win32 Programmer Needs to Know.

Alex
A: 

One option, and its pure mind games, is to provide a progress bar on load...

If people have something to look at it distracts them and makes it "feel" quicker, that's why there are mirrors between elevators that serve numerous floors...

This won't beat a stopwatch though...

The other alternative is to re-write it to use less DLLs. How much of a budget (money/time) you have is the next question

MadMurf
+2  A: 

A couple of things I guess you need to know:

  • Many small files is way slower then a couple of big files
  • Disk access is much slower then memory access (DLLs need to be loaded from disk)

Reducing the amount of DLLs is a must in this situation. Maybe you can combine then, but I guess it's a modular design, which means, most of the times, they cannot be combined.

You could also load the DLLs on use, instead of on opening of the program and only load the necessary DLLs to load the program on startup.

Or you could even delay the loading of DLLs by first starting the program with the necessary DLLs and then load the others, on order of importance to use.

Michiel
Modular doesn't have to mean inordinate amounts of DLLs.
Alex
That is correct. But some modular design patterns, could get in the way, when you want to change the loading or file structure.
Michiel
+1  A: 

If you have access to the code of the dlls ( or some of them ) you could look for candiates to staticly link. If you can convert a bunch of them to static libraries, you could speed up the startup dramaticaly.

DarthCoder
+6  A: 

You need to profile your application in order to determine the true cause of the slowdown. For example, it could be that you are spending most of the time in some initialization routine of one the .dll's you are loading. Go find yourself a good profiling tool and then determine where the bottleneck is.

zr
could you recommend a tool to profile my application? Thanks.
Yigang Wu
My favorite tool is VTune. It is not for free, but you can download a 30 day evaluation copy:http://software.intel.com/en-us/intel-vtune/
zr
The profiler isn't going to show much of anything interesting, unless it knows how to profile the hard drive.
Hans Passant
Indeed. Listen to nobugz. You aren't trying to find a bottle neck in some time-critical loop. It's the startup that's the problem.
Alex
@nobugz:I disagree with your statement. If indeed the reason for the slow startup time is the process doing lots of i/o, this will be visible in the profiler. You will see the CPU being idle and waiting for some system call to complete.
zr
+1  A: 

Use lazy construction of static objects.

Instead of having globals that get created during start-up, like this:

Foo foo;
Bar bar;

int main()
{
    // Access foo and bar
}

Have them constructed on demand with the following idiom:

Foo & foo()
{
    static Foo the_instance;
    return the_instance;
}
Bar & bar()
{
    static Bar the_instance;
    return the_instance;
}

int main()
{
    // Access objects through foo() and bar()
}

This will save you some start-up time if the objects are expensive to create (e.g., have to build up large look-up tables or perform heavy IO).

This will no help with loading those DLL's though.

Manuel
+1  A: 

You're getting good advice here. Having many DLLs is one of those passing fads that you are now paying for. In addition, initializing them may be doing a lot more than you need.

There's a simple way to tell what's taking the time. Start the app under an IDE, such as Visual Studio, and while it's starting up, hit the "Pause" button and display the call stack. Do this several times. Each time, you will see what it is doing and, most importantly, why. If you see that it is spending much time doing something that you don't really need, then that tells you what to fix.

Mike Dunlavey
Poor man's profiling. Nice.
Thomas
@Thomas: Right, and you might be surprised how effective it is: http://stackoverflow.com/questions/926266/performance-optimization-strategies-of-last-resort/927773#927773
Mike Dunlavey