Speed initial load
-
I've created a big program (2.5M) and it's loading slowly on startup. Could someone please point me to ideas on how to improve this. Many of the subroutines are rarely or never needed by many users. So I'm thinking of putting them in separate .dlls. Would that help? Tia
-
I've created a big program (2.5M) and it's loading slowly on startup. Could someone please point me to ideas on how to improve this. Many of the subroutines are rarely or never needed by many users. So I'm thinking of putting them in separate .dlls. Would that help? Tia
Breaking the application to smaller pieces using dll's would help. However, if the application size is 2.5MB and it's starting up slowly, I would guess that the problem is somewhere else. Perhaps you're doing lot's of initializations in the beginning. Also you could check the compiler settings and let it do optimizations and remove the debug constant.
The need to optimize rises from a bad design.My articles[^]
-
I've created a big program (2.5M) and it's loading slowly on startup. Could someone please point me to ideas on how to improve this. Many of the subroutines are rarely or never needed by many users. So I'm thinking of putting them in separate .dlls. Would that help? Tia
If you've got a ton of code in your startup form or an excessive number of controls on it, then this is going to be a problem. To partially solve the problem of a large code-base, you can move non-UI involved code to another class (class library). If you have an excessive number of controls, there's nothing you can do about it except re-design your app. You can also try running NGEN on the installed application to generate the native code assemblies for that machine, but don't count on a huge performance gain from this.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
If you've got a ton of code in your startup form or an excessive number of controls on it, then this is going to be a problem. To partially solve the problem of a large code-base, you can move non-UI involved code to another class (class library). If you have an excessive number of controls, there's nothing you can do about it except re-design your app. You can also try running NGEN on the installed application to generate the native code assemblies for that machine, but don't count on a huge performance gain from this.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008Thanks to you both. So the code in the class libraries is not loaded by my program until it is needed, saving time on startup? Is that the idea?
-
Thanks to you both. So the code in the class libraries is not loaded by my program until it is needed, saving time on startup? Is that the idea?
Yep. entire assmeblies are not compiled when needed. The JIT compiler only compiles what is needed at the time, if it hasn'y already been compiled. You can have an assembly with (bite-my-tongue) 1,000 methods in it, so only them method being called will get compiled at the time it's needed. The remaining methods won't be compiled until they're needed.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
Yep. entire assmeblies are not compiled when needed. The JIT compiler only compiles what is needed at the time, if it hasn'y already been compiled. You can have an assembly with (bite-my-tongue) 1,000 methods in it, so only them method being called will get compiled at the time it's needed. The remaining methods won't be compiled until they're needed.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008But that last comment, Dave, makes it sound as if this is true for all methods, not just methods in the accompanying class libraries. So why is there an advantage of moving code from the .exe into the .dlls?
-
But that last comment, Dave, makes it sound as if this is true for all methods, not just methods in the accompanying class libraries. So why is there an advantage of moving code from the .exe into the .dlls?
Having everything in a monolithic .EXE file takes the loader forever to load and process, setup the runtime environment (.NET CLR), pass control to the CLR, which reads what it needs, compiles the necessary methods, if not already previously done, and calls the entry point of the code, which will call other methods in the code, and finally getting around to calling InitializeComponent for all of the controls, again, more compiling, and creating an instance of the form. There's a LOT that happens before you see your startup form...
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
Having everything in a monolithic .EXE file takes the loader forever to load and process, setup the runtime environment (.NET CLR), pass control to the CLR, which reads what it needs, compiles the necessary methods, if not already previously done, and calls the entry point of the code, which will call other methods in the code, and finally getting around to calling InitializeComponent for all of the controls, again, more compiling, and creating an instance of the form. There's a LOT that happens before you see your startup form...
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008