Jump to content
Dany Marmur

How to optimize exe loading times

Recommended Posts

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.

  • Like 2

Share this post


Link to post
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.

Share this post


Link to post
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 😄)

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

@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.

Share this post


Link to post

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.

  • Like 1

Share this post


Link to post

@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.

  • Thanks 1

Share this post


Link to post
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?

Share this post


Link to post

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.

 

Share this post


Link to post
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 🙂

Share this post


Link to post

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.
 

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post
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 😉

Share this post


Link to post
15 hours ago, Anders Melander said:

...at least one too many :classic_wink:

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

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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?

Share this post


Link to post

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. 

Share this post


Link to post
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.

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×