6

I have a dpr with 290+ units.

The compiled exe is 50MB.

The dpr code is now like this:

begin
  ShowMessage('Before Initialize');
  Application.Initialize;

When I double click on the built exe I notice that 8 seconds pass before I see "Before Initialize". Is this because of big exe size? Or is there a way to minimize this time?

Toon Krijthe
  • 52,876
  • 38
  • 145
  • 202
UnDiUdin
  • 14,924
  • 39
  • 151
  • 249

5 Answers5

17

Before Application.Initialize every initialization section of every unit is executed. You might have some code in there that takes time.

The number of units is not the problem. I have a project with 1100+ units, exe is 35 MB and it starts instantaneously.

If you are starting from network drive or really slow disk you might experience a slowdown.

Mikael Eriksson
  • 136,425
  • 22
  • 210
  • 281
  • 4
    You may be able to diagnose where the program is spending its time by sticking a profiler (e.g. http://delphitools.info/samplingprofiler/) on it during startup. – David Heffernan Jan 20 '11 at 12:49
  • 4
    Could also be caused by an antivirus program. – gabr Jan 20 '11 at 13:37
  • 5
    Quick tip: As above, Initialization sections in your application are executed, but also, initialization sections for your components are executed. One big slowdown I found at startup (up to 60 seconds delay) was due to a printer-properties-dialog-component that was trying to query properties of a network printer that I had installed in control panel, that was not responding. Mapped network drives and other network resources that are not responding, and component initializations can be a problem area. Use AQTime, which comes with RAD Studio XE, to profile your app. – Warren P Jan 20 '11 at 14:19
  • @David Heffeman Thanks for the link, I tried the sampling profiler and in module WindowsCodecs.dll there is "Unit ???" "Procedure ???" that takes 6667 samples (out of 20000 total). What does it mean? – UnDiUdin Jan 20 '11 at 14:33
  • @Warren P: I checked. my initialization code is almost instantaneously executed, anyway a lot is there in the components. I will try with an instrumentig profiler too. I am just migrating to XE, even if I own ProDelphi profiler. I will try with both. – UnDiUdin Jan 20 '11 at 14:34
4

Based on your question, it can be anything.

The only advice I can give you is to measure:
Log the timestamps of every entry/exit in all your unit initialization sections.

Based on one of your comments (which you should add to your question as it describes more detail):

WindowsCodecs.dll is initialized by one of your units, probably converting one or more images from one format into another.
You should delay the conversion until the result of that conversion is needed.

--jeroen

Jeroen Wiert Pluimers
  • 23,965
  • 9
  • 74
  • 154
  • How can I check which line of code causes WindowsCodec.dll to be called? – UnDiUdin Jan 20 '11 at 17:23
  • 1
    That can be tough; what you could do is in the Delphi Modules window, set a breakpoint on the loading of the WindowsCodec.dll, then watch the stack during the breakpoint. – Jeroen Wiert Pluimers Jan 20 '11 at 18:19
  • 5
    Finally I downloaded AQTime Profiler trial and I found the problem to be in a 3rd party library initialization code. – UnDiUdin Jan 28 '11 at 09:19
1

The initialization section of the units is normally not a speed problem (unless you have some database-related stuff in there).

What could be slow is the TForm loading from resources.

It's always better to have the TForm created on the fly, only when it's necessary: - Go to "Project" menu, then select "Options", then the "Forms" tab. - Put all not mandatory forms from left list to the right "available" list. - Create the forms on request, by some code.

The unit remains the same:

type
  TOneForm = class(TForm)
  ....
  end;

var
  OneForm: TOneForm;

But you can use the following code to create the form on request:

Instead of your former

  OneForm.ShowModal;

uses this kind of code

  if OneForm=nil then
    OneForm := TOneForm.Create(Application);
  OneForm.ShowModal;

You'll find the loading of the application much faster.

Note: I just read out that the problem was before form loading. So the above trick won't work for this particular problem. I keep the answer because it could be useful to others. I'll read better next time. :(

In all cases, having a lot of code run from the initialization is not a good design. It sounds like a lot of global objects or variables... refactoring could make sense here... :)

Arnaud Bouchez
  • 42,305
  • 3
  • 71
  • 159
1

You already know that if you have a lot of forms, try moving the forms out of the "auto create" list, and then add code, to create the forms when they are needed, but you are seeing this problem before you could even create a form. So, as others have said, initialization sections are the problem.

Jeroen's blog pointed me at a great resource for debugging this:

http://wiert.wordpress.com/2010/07/21/delphi-great-post-by-malcolm-groves-about-debugging-initialization-and-finalization-sections/

He pointed me to Malcom Groves:

http://www.malcolmgroves.com/blog/?p=649

Warren P
  • 65,725
  • 40
  • 181
  • 316
1

There are a lot of good suggestions in this question.

You should absolutely make sure you aren't creating things on startup that you don't need right away. This usually the biggest launch delay on projects with a lot of forms.

In your case, is sounds like a lot of initialization code is being executed.

Community
  • 1
  • 1
Bruce McGee
  • 15,076
  • 6
  • 55
  • 70