How to optimize exe loading times

[Lars Fosdal 1791]

On 11/27/2020 at 5:16 PM, Attila Kovacs said:

At least a splash screen would be nice.

 

You don't want to put your db connection into a thread. Nor many other things.

 

It's so 90's. ctrl+shift+esc

If your main window pops up immediately, you may not need that splash at all.
What is it supposed to tell the user? 

Why not put the db connections in threads?
Everything and anything can be asynchronous if you do it right.

[aehimself 396]

On 11/27/2020 at 5:16 PM, Attila Kovacs said:

You don't want to put your db connection into a thread. Nor many other things.

That is actually (half of) the best thing(s) that can happen to an application. The other half is, having dataset operations (.Open, .Post, .Refresh, etc.) in the same thread.

[Attila Kovacs 629]

@aehimself Okay, why?

[aehimself 396]

Just now, Attila Kovacs said:

@aehimself Okay, why?

Connecting - 15 seconds. Application stops responding.

Opening a large dataset with lots of BLOB fields - 1 hour. Application still does not respond.

Make a change, post it back and commit. Another 5 seconds of white screen. But noone really cares at this point.

 

For ease of code, put everything on your form. For everything else, there are Threads.

 

(powered by Loreal and Mastercard 😄)

[Guest]

Server side non REST i pool complete DM's with connection and queries.

Server side REST i event pool DMs with prepared statements that match the parameters of the next request(s).

Client side is another matter. Clients really do not need to multi-thread SQL stuff, IMHO.

If the need arises, a middle-tier is a better solution barring all other tings. Then, to do local stuff neatly threads can be used galore.

It is possible to create a MT-client using TDataSet based components but i would not recommend to embark on that journey.

[Lars Fosdal 1791]

We do extensive use of client-side threading. 
Lengthy UI blocking jobs, such as querying for data or generating output, are delegated to a thread - culminating in a UI refresh to display the updated data.
"Not responding" UI messages are so last decade.

[Lars Fosdal 1791]

For some it can be daunting to get started on multi-threading and asynchronous applications.

@Dalija Prasnikar can help with that.
https://dalijap.blogspot.com/2020/11/just-released-ebook-delphi-event-based.html

[Mike Torrettinni 198]

@Dany Marmur Did you discover what was the cause of the slow loading time? What tools did you use? Any interesting discoveries?

I'm interested in anything useful that I could apply to my projects, if applicable, of course.

[Fr0sT.Brutal 900]

Anything after Application.Initialize is easy to track... the trick is when some earlier actions cause slowdown.

When running app in IDE by F7, process is stopped at the entrypoint when all binary file reads and necessary resource loads are made by OS. Then, enabling "Use debug DCUs" and "Trace into", you can trace System.InitUnits that executes all init sections of used units. Something like a non-breaking breakpoint at line "TProc(P)();" with options "Eval expression" = "inttostr(i) + ' ' + inttostr(gettickcount)" will give timings. When the villain's index is spotted, you can "Trace into" the above line to find out what unit it is.

[Guest]

@Mike Torrettinni, it seems to be due to hard use of the DevExpress LayoutControl.

Sampling Profiler points there, running instrumenting during dfm loading has been a little tricky.

Sadly i have had to put this issue back for a while.

[Anders Melander 1782]

3 hours ago, Dany Marmur said:

it seems to be due to hard use of the DevExpress LayoutControl.

So the problem isn't actually related to "How to optimize exe loading times" but rather "how to speed up form loading"...?

 

I use the layout control a lot, and on complex forms it can become a bit slow, but I've never had it affect application startup time or the time it takes for the main form to display. You aren't by chance "auto creating" your forms?

[Lars Fosdal 1791]

The only two forms I auto create is a login form and the main form.

All dialogs, as well as all frames on the main form, are created dynamically based on user input. 

Never used? Never created.

 

[Anders Melander 1782]

1 hour ago, Lars Fosdal said:

The only two forms I auto create is

...at least one too many

[Guest]

2 hours ago, Anders Melander said:

So the problem isn't actually related to "How to optimize exe loading times" but rather "how to speed up form loading"...?

Most definitely. But i did not know that when i started the tread 🙂

[Clément 148]

I'm also using DevExpress a lot and never experience such startup delay.
I'm autocreating  Main Form, and some data modules (image lists, skin controllers, and the like ) required for the whole lifetime of the application. I'm creating manually everything else, including the login form.

 

I'm having a painting performance issue with their forms, especially with acrylic effect.
 

[Anders Melander 1782]

12 minutes ago, Dany Marmur said:

Most definitely. But i did not know that when i started the tread 🙂

Compile and press F7 and you'd know.

 

9 minutes ago, Clément said:

I'm autocreating  Main Form, and some data modules (image lists, skin controllers, and the like ) required for the whole lifetime of the application.

I would recommend that you change the autocreate datamodules so they're created on-demand instead. That way you'll defer the overhead until the datamodule is actually needed.

Something like:

type
  TMyBigDataModule = class(TDataModule)
  ...
  end;

function MyBigDataModule: TMyBigDataModule;

implementation

var
  FMyBigDataModule: TMyBigDataModule;

function MyBigDataModule: TMyBigDataModule;
begin
  if (FMyBigDataModule = nil) then
    FMyBigDataModule := TMyBigDataModule.Create(Application);
  Result := FMyBigDataModule;
end;

 

18 minutes ago, Clément said:

I'm having a painting performance issue with their forms, especially with acrylic effect.

Yeah. All those features and versatility definitely comes at a price.

Since they switched to a subscription only model they have become become lazy with regard to avoiding dependencies and so the applications become pretty bloated. Put a simple grid on a form and you get much of the spreadsheet stuff linked in as well.

[Attila Kovacs 629]

On 12/17/2020 at 4:37 PM, Fr0sT.Brutal said:

"Use debug DCUs" and "Trace into", you can trace System.InitUnits that executes all init sections of used units. Something like a non-breaking breakpoint at line "TProc(P)();" with options "Eval expression" = "inttostr(i) + ' ' + inttostr(gettickcount)" will give timings. When the villain's index is spotted, you can "Trace into" the above line to find out what unit it is.

this sounds familiar to me 😉

[Lars Fosdal 1791]

15 hours ago, Anders Melander said:

...at least one too many

Well, I could create it explicitly, but it would be practically the same code? 

[Anders Melander 1782]

1 hour ago, Lars Fosdal said:

Well, I could create it explicitly, but it would be practically the same code? 

Yes but by doing it explicitly, at the point of your choice, you control exactly when it happens. The autocreate form/datamodule code, using TApplication.CreateForm, is managed by the IDE and it has been known to mess that up once you start editing the dpr file.

[Lars Fosdal 1791]

True that hand-editing the .dpr file is a chance game.  To the point that I sometimes keep the code in a separate comment block so that I can quickly restore what the IDE screwed up.

But having two forms auto created isn't the problem in that context.

[Fr0sT.Brutal 900]

On 12/19/2020 at 1:38 PM, Lars Fosdal said:

To the point that I sometimes keep the code in a separate comment block so that I can quickly restore what the IDE screwed up. 

Really sly solution, why not just VCS?

[Lars Fosdal 1791]

Because I'm most likely adding forms to the app and want to keep the uses list changes, but not keep the changes to the auto-creates, which may have seriously modified the startup code. 

Ideal? No. Pragmatic? Yes. A quick cut&paste. 

[Fr0sT.Brutal 900]

2 hours ago, Lars Fosdal said:

Because I'm most likely adding forms to the app and want to keep the uses list changes, but not keep the changes to the auto-creates, which may have seriously modified the startup code. 

Ideal? No. Pragmatic? Yes. A quick cut&paste. 

Still couldn't get your point. Or maybe I didn't explained mine. When I commit changes to VCS, I inspect changes to DPR and revert unneeded ones if IDE screwed up some sections again.

[jsjr 0]

new member long time delphi user (27 years + turbo before that) sorry if this is in wrong place have 2 D5 programs where exe is about 6mb in size...when I run in ide and click F7 to get to the first begin stmt one takes 12 seconds while the other takes about 2 seconds trying to determine what the slow prog is doing for all the time.  Pretty fast machine with SSD so 12 seconds is a lot of work being done.  "Use debug DCUs" is disabled in my ide for some reason so have not been able to use that.

Ideas on why and how to figure out why are appreciated