Lars Fosdal 1793 Posted November 30, 2020 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. 2 Share this post Link to post
aehimself 399 Posted December 1, 2020 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
aehimself 399 Posted December 1, 2020 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
Guest Posted December 1, 2020 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
Lars Fosdal 1793 Posted December 3, 2020 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. 1 Share this post Link to post
Lars Fosdal 1793 Posted December 3, 2020 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 1 Share this post Link to post
Mike Torrettinni 198 Posted December 17, 2020 @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
Fr0sT.Brutal 900 Posted December 17, 2020 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. 1 Share this post Link to post
Guest Posted December 18, 2020 @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. Share this post Link to post
Anders Melander 1804 Posted December 18, 2020 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
Lars Fosdal 1793 Posted December 18, 2020 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
Anders Melander 1804 Posted December 18, 2020 1 hour ago, Lars Fosdal said: The only two forms I auto create is ...at least one too many Share this post Link to post
Guest Posted December 18, 2020 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
Clément 148 Posted December 18, 2020 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
Anders Melander 1804 Posted December 18, 2020 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. 1 Share this post Link to post
Attila Kovacs 631 Posted December 18, 2020 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
Lars Fosdal 1793 Posted December 19, 2020 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? Share this post Link to post
Anders Melander 1804 Posted December 19, 2020 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
Lars Fosdal 1793 Posted December 19, 2020 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
Fr0sT.Brutal 900 Posted December 20, 2020 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
Lars Fosdal 1793 Posted December 21, 2020 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
Fr0sT.Brutal 900 Posted December 21, 2020 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. 1 Share this post Link to post
jsjr 0 Posted February 11, 2022 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 Share this post Link to post