views:

1142

answers:

11

What do you do to increase startup speed (or to decrease startup time) of your Delphi app?

Other than application specific, is there a standard trick that always works?

Note: I'm not talking about fast algorithms or the likes. Only the performance increase at startup, in terms of speed.

+13  A: 

Try doing as little as possible in your main form's OnCreate event. Rather move some initialization to a different method and do it once the form is shown to the user. An indicator that the app is busy with a busy mouse cursor goes a long way.

Experiments done shows that if you take the exact same application and simply add a startup notification to it, users actually perceive that app as starting up faster!

Other than that you can do the usual things like exclude debug information and enable optimization in the compiler.

On top of that, don't auto create all your forms. Create them dynamically as you need them.

Maltrap
So, what is a good startup notification? I dislike splash screens personally. What else could it be anyway?
utku_karatas
Anything from a status message telling the user what you're doing after your main form is shown to a little label somewhere on the main form. A progress bar is also useful if possible, alternatively a spinning progress bar.
Maltrap
@utkuI understand your dislike of splash screens, but they're useful when the main form doesn't show right away. Otherwise, your user might not know the app has started and try to re-launch it.
Bruce McGee
R.E. splash screen, how about a picture of the main form - it looks like it's started up quickly, even though you cannot do anything with it. A bit like Vista, really. ;-)
HMcG
+26  A: 

In the project options, don't auto-create all of your forms up front. Create and free them as needed.

Bruce McGee
+1 - and let me add: open any connection, be it database, internet, COM or whatever, at the time you need it first.
Uwe Raabe
@Uwe: your comment is distinct enough that it should've been a separate answer. I'd do it except I'd look like a rep hound, and though I could make my answer CW, but then you wouldn't get the rep.
Argalatyr
@Argalatyr: Thanks for the suggestion
Uwe Raabe
+11  A: 

Three things happen before your form is shown:

  1. All 'initialization' blocks in all units are executed in "first seen" order.
  2. All auto-created forms are created (loaded from DFM files and their OnCreate handler is called)
  3. You main form is displayed (OnShow and OnActivate are called).

As other have pointed out, you should auto-create only small number of forms (especially if they are complicated forms with lots of component) and should not put lengthy processing in OnCreate events of those forms. If, by chance, your main form is very complicated, you should redesign it. One possibility is to split main form into multiple frames which are loaded on demand.

It's also possible that one of the initialization blocks is taking some time to execute. To verify, put a breakpoint on the first line of your program (main 'begin..end' block in the .dpr file) and start the program. All initialization block will be executed and then the breakpoint will stop the execution.

In a similar way you can step (F8) over the main program - you'll see how long it takes for each auto-created form to be created.

gabr
+14  A: 

Well, as Argalatyr suggested I change my comment to a separate answer:

As an extension to the "don't auto create forms" answer (which will be quite effective by itself) I suggest to delay opening connections to databases, internet, COM servers and any peripheral device until you need it first.

Uwe Raabe
+3  A: 

Display a splash screen, so people won't notice the long startup times :).

jqno
And it acts as a form of product branding.
Bruce McGee
A: 

Fastest code - it's the code, that never runs. Quite obvious, really ;)

Alexander
Obvious...true. But not that helpful either.
Smasher
+2  A: 

Deployment of the application can (and usually does!) happen in ways the developer may not have considered. In my experience this generates more performance issues than anyone would want.

A common bottleneck is file access - a configuration file, ini file that is required to launch the application can perform well on a developer machine, but perform abysmally in different deployment situations. Similarly, application logging can impede performance - whether for file access reasons or log file growth.

What I see so often are rich-client applications deployed in a Citrix environment, or on a shared network drive, where the infrastructure team decides that user temporary files or personal files be stored in a location that the application finds issues with, and this leads to performance or stability issues.

Another issue I often see affecting application performance is the method used to import and export data to files. Commonly in Delphi business applications I see export functions that work off DataSets - iterating and writing to file. Consider the method used to write to file, consider memory available, consider that the 'folder' being written to/read from may be local to the machine, or it may be on a remote server.

A developer may argue that these are installation issues, outside the scope of their concern. I usually see many cycles of developer analysis on this sort of issue before it is identified as an 'infrastructure issue'.

Jason T
+2  A: 
  • First thing to do is to clear auto created forms list (look for Project Options). Create forms on the fly when needed, especially if the application uses database connection (datamodule) or forms that include heavy use of controls.
  • Consider using form inheritance also to decrease exe size (resource usage is mimized)
  • Decrease number of forms and merge similar or related functionality into single form
Use inheritance to decrease EXE size? That sounds odd to me...perhaps you can explain what you mean. And if you follow your first point, your last point will probably not be necessary...
Smasher
Say you have a two table db app. And you have two different forms listing data basically. And you have controls that activate CRUD operations using other forms. If you use some design patterns and move out the 'logic' out of these forms then you would not create forms for each table. But still you have a point in saying my first and last have some contradiction in a way. Hope this explanation makes it a bit clear. (And telling you to do so does not mean I always can implement it successfully :))
+2  A: 

Put long running tasks (open database connections, connect to app server, etc) that have to be performed on startup in a thread. Any functionality that depends on these tasks are disabled until the thread is done.

It's a bit of a cheat, though. The main form comes up right away, but you're only giving the appearance of faster startup time.

Bruce McGee
+1  A: 

Compress your executable and any dlls using something like ASPack or UPX. Decompression time is more than made up for by faster load time.

UPX was used as an example of how to load FireFox faster.

Note that there are downsides to exe compression.

Bruce McGee
A: 

This is just for the IDE, but Chris Hesick made a blog posting about increasing startup performance under the debugger.

Bruce McGee