|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Startup speedI have created an VB.Net application, but I found the startup speed is
really slow. Once I start the application and I close it and re-open, The speed is much faster, I know that this is common on all applications, but is there any method to make the first time startup faster? Thank you! Hi Cylix ,
1. This might be caused by the library`s that you reference in your project , the second time you start these are preloaded and so the startup is much faster 2. you migh encounter a slow first start on new applications as they are compiled on the fly , however this should only happen on a first start all subsequent starts should be faster ( as .net optimizes the assembly for the system ) ,,, you can also avoid this by precompiling the application although i would not recomend this as you miss the system optimizations ( this might be handy in a corporate environment where computers all have the same specs ) what if non of the above is plausible in your situation ,, you just have a big hungry app that starts slow , well first of all a redesign might be on it`s place as something has gone wrong ,,,,,another solution might be to preload your app on startup hth Michel Posseth [MCP] Show quoteHide quote "Cylix" <cylix2***@gmail.com> schreef in bericht news:1152247709.991965.242690@s13g2000cwa.googlegroups.com... >I have created an VB.Net application, but I found the startup speed is > really slow. > Once I start the application and I close it and re-open, > The speed is much faster, I know that this is common on all > applications, > but is there any method to make the first time startup faster? > > Thank you! > Michel Posseth [MCP] wrote:
> 2. you migh encounter a slow first start on new applications as they are Michel,> compiled on the fly , however this should only happen on a first start all > subsequent starts should be faster ( as .net optimizes the assembly for the > system ) Are you saying that only the /first/ .Net application [process] that starts after booting the machine is slow, but that subsequent applications [processes] will be quicker? I have an application that could potentially build up to be some 400 individual Forms applications, each started from a coordinating (currently VC++ 6) application, but where each is a separate process. The first one of these .Net app's to be started [each morning] is /intolerably/ slow. Could I improve things by having my "core" application launch a (non-visible) .Net application to "pre-load" the run-time and some of my UserControl-type assemblies? In your opinion, would this speed up the loading of other .Net processes? TIA, Phill W. Hello Phill
Sorry for my late reaction , ( i was in the weekend on a trip to Belgium with my wife :-) ,,, picked up some Belgium Culture, Beers and Chocolate on the way ) My experience is indeed that subsequent starts are much faster , By the way : I work currently for a company , that does a redesign of it`s hole production system to VS.Net 2005 ( VB ) the former program was written in COBOL somewhere early in the eighties ( but works with lightning speed ,, even now :-( ) as this is a energy service company you understand we have to build a lot of forms , reports etc etc . We solved the slow start problem by creating a menu application ( one app that acts as interface ) to all satelite programs the satelites are actually seperate executables we created dll`s for comon tasks that are done in multiple exe`s , we have now almost instant response we start the satelite programs with process start ( so no referencing there ) , the dll`s are all referenced and we built this way a module application a big benefit is that we can release parts of the program now that are test ready , and can do maintenance without interfering the rest of the app maybe the above is a nice idea for you to ? regards Michel Posseth [MCP] Show quoteHide quote "Phill W." <p-.-a-.-w-a-r-d@o-p-e-n-.-a-c-.-u-k> schreef in bericht news:e8lkpr$69i$1@yarrow.open.ac.uk... > Michel Posseth [MCP] wrote: > >> 2. you migh encounter a slow first start on new applications as they are >> compiled on the fly , however this should only happen on a first start >> all subsequent starts should be faster ( as .net optimizes the assembly >> for the system ) > > Michel, > > Are you saying that only the /first/ .Net application [process] that > starts after booting the machine is slow, but that subsequent applications > [processes] will be quicker? > > I have an application that could potentially build up to be some 400 > individual Forms applications, each started from a coordinating (currently > VC++ 6) application, but where each is a separate process. The first one > of these .Net app's to be started [each morning] is /intolerably/ slow. > > Could I improve things by having my "core" application launch a > (non-visible) .Net application to "pre-load" the run-time and some of my > UserControl-type assemblies? In your opinion, would this speed up the > loading of other .Net processes? > > TIA, > Phill W. Michel,
Sounds remarkably familiar, just replacing "COBOL" with "C++" for the "menu" application and "VB" (and now VB.Net) for the satellite programs. Regards, Phill W. Michel Posseth [MCP] wrote: Show quoteHide quote > Hello Phill > > > Sorry for my late reaction , ( i was in the weekend on a trip to Belgium > with my wife :-) ,,, picked up some Belgium Culture, Beers and Chocolate on > the way ) > > My experience is indeed that subsequent starts are much faster , > > By the way : > > I work currently for a company , that does a redesign of it`s hole > production system to VS.Net 2005 ( VB ) the former program was written in > COBOL somewhere early in the eighties ( but works with lightning speed ,, > even now :-( ) as this is a energy service company you understand we > have to build a lot of forms , reports etc etc . > > We solved the slow start problem by creating a menu application ( one > app that acts as interface ) to all satelite programs the satelites are > actually seperate executables we created dll`s for comon tasks that are > done in multiple exe`s , we have now almost instant response > > we start the satelite programs with process start ( so no referencing > there ) , the dll`s are all referenced and we built this way a module > application a big benefit is that we can release parts of the program now > that are test ready , and can do maintenance without interfering the rest of > the app > > > maybe the above is a nice idea for you to ? > > > regards > > Michel Posseth [MCP] > > > > > > > "Phill W." <p-.-a-.-w-a-r-d@o-p-e-n-.-a-c-.-u-k> schreef in bericht > news:e8lkpr$69i$1@yarrow.open.ac.uk... >> Michel Posseth [MCP] wrote: >> >>> 2. you migh encounter a slow first start on new applications as they are >>> compiled on the fly , however this should only happen on a first start >>> all subsequent starts should be faster ( as .net optimizes the assembly >>> for the system ) >> Michel, >> >> Are you saying that only the /first/ .Net application [process] that >> starts after booting the machine is slow, but that subsequent applications >> [processes] will be quicker? >> >> I have an application that could potentially build up to be some 400 >> individual Forms applications, each started from a coordinating (currently >> VC++ 6) application, but where each is a separate process. The first one >> of these .Net app's to be started [each morning] is /intolerably/ slow. >> >> Could I improve things by having my "core" application launch a >> (non-visible) .Net application to "pre-load" the run-time and some of my >> UserControl-type assemblies? In your opinion, would this speed up the >> loading of other .Net processes? >> >> TIA, >> Phill W. > > 
Other interesting topics
|
|||||||||||||||||||||||
