Slow startup for .NET applications

[kimiraikkonen]

Hi there,
I figured out, for the first execution for any .NET-powered app such
as VB.NET or C#, it takes 7-8 seconds to see main form of "any"
application even the application consists of a single form and a
button and only 32kb sized. The second execution(without rebooting
machine) is done less than a second.

This slowdown on startup doesn't occur on non-.NET-powered apps such
as VB6, MFC or VC++ 6 applications. If an application is powered
by .NET it takes 7-8 seconds to open, to see the first form.

However, i think that a kind of framework is being loaded into memory
for the first time of execution, then the second opening is done less
than a second due to framework is still in the memory i suppose or
kinda.

I heard some techiniques for accelerating slow startup on .NET apps,
but none of them i know good.

Note: I have 1gb DDR memory + 2.4GHZ processor with a lot of free
system resource which must mean more than "enough" for .NET.

I hope someone could explain why non-.NET-powered apps is opened less
than a second(double-click) but .NET apps is opened in 7-8 seconds for
the first execution.

Thanks.

 

[Michel Posseth [MCP]]

AFAIK

This happens because of Compilation , as long as the assembly stays at the
same location and the version doesn`t change it should still start instantly
also after a reboot

HTH

Michel

 

[Herfried K. Wagner [MVP]]

I figured out, for the first execution for any .NET-powered app such
as VB.NET or C#, it takes 7-8 seconds to see main form of "any"
application even the application consists of a single form and a
button and only 32kb sized. The second execution(without rebooting
machine) is done less than a second.

Note that executing a .NET-based application requires startup of the Common
Language Runtime (CLR) and loading of some larger libraries ("mscorlib",
"System.Windows.Forms.dll" for Windows Forms applications,
"Microsoft.VisualBasic.dll", and some other DLLs respectively). This will
take some time. In addition, the Just-In-Time compiler (JIT compiler) will
have to translate the Intermediate Language code (IL code) to machine code
prior to execution of a method).

After starting a .NET application, the required files are already placed in
the (disk) cache and thus startup time will be drastically reduced.

 

[kimiraikkonen]

AFAIK

This happens because of Compilation , as long as the assembly stays at the
same location and the version doesn`t change it should still start instantly
also after a reboot

HTH

Michel

I don't think so, though no location or no code change, but after next
reboot, again it takes 7-8 seconds to open app for the first
execution. Second execution without reboot takes less than a second.
Something is being loaded into memory i supposed? However there are
some this issue-related threads in group which seems common,
experienced on many different computers for only .net. No problem in
VB6 or MFC powered apps about startup time.

PS: Using .net framework 2.0, XP SP2.

Regards.

 

[Michel Posseth [MCP]]

Interesting .......

Just did some tests on my private system , DELL Dimension , Intell E6400 a
VIIV version of that processor , 2 GB Memory 667 mhz , Geforce 7900 GS 256
MB , SATA Stripe 500 Gb with Windows mediacenter 2005
1, 2 , 3 program starts , second time boef program is there instantly ,
start other program ( wich uses data etc etc ) 1,2 program starts , second
time boef program is there instantly

i copy one of the programs that start instantly to another location on my
disk , 1,2 program starts second time boef program is there instantly

I have once read that the compile mechanism worked that way and to my tests
it seems to be right with a litle twist , i guess the answer can be found in
Herfried`s reply
and that my findings are a combination of the compile mechanism and the
preloading of the .Net runtime makes the difference

It also seems that if you have some bether hardware it is not so disturbing

Michel

 

[kimiraikkonen]

Interesting .......

Just did some tests on my private system , DELL Dimension , Intell E6400 a
VIIV version of that processor , 2 GB Memory 667 mhz , Geforce 7900 GS 256
MB , SATA Stripe 500 Gb with Windows mediacenter 2005
1, 2 , 3 program starts , second time boef program is there instantly ,
start other program ( wich uses data etc etc ) 1,2 program starts , second
time boef program is there instantly

i copy one of the programs that start instantly to another location on my
disk , 1,2 program starts second time boef program is there instantly

I have once read that the compile mechanism worked that way and to my tests
it seems to be right with a litle twist , i guess the answer can be found in
Herfried`s reply
and that my findings are a combination of the compile mechanism and the
preloading of the .Net runtime makes the difference

It also seems that if you have some bether hardware it is not so disturbing

Michel

So this is a kind of confirmation though you have much better hardware
but still the latency between two executions is visible.

So, it seems that there isn't much thing to do except upgrading
hardware to accelerate .NET apps' startup. I wish .NET was as fast as
VB6 or other non-.NET technolgies like old VC++, MFC
apps(before .NET), but its powerful classes are better/innovative of
course for developers.

Thanks.

 

[Tom Shelton]

So this is a kind of confirmation though you have much better hardware
but still the latency between two executions is visible.

So, it seems that there isn't much thing to do except upgrading
hardware to accelerate .NET apps' startup. I wish .NET was as fast as
VB6 or other non-.NET technolgies like old VC++, MFC
apps(before .NET), but its powerful classes are better/innovative of
course for developers.

Thanks.- Hide quoted text -

- Show quoted text -

In general, well written .NET apps are not significantly slower then
those other technologies you mention (and in some cases faster). The
biggest performance hit is really in startup, especially cold
startup... Once the framework is in the disk cache, this startup time
is significantly reduced. There are techniques, such as using ngen
that can speed up that time, but like everything there are pro's and
con's to it's use.

 

[Gilles Ganault]

In general, well written .NET apps are not significantly slower then
those other technologies you mention

But then, how can we write apps more efficiently when even a basic
form with just a single push-button takes several seconds, while its
VB Classic takes less than a second?

Besides compiling the .Net app before distributing it to customers and
avoid the JIT kicking-in, Isn't it possible to load .Net stuff at
boot-time, so it's available in RAM whenever a .Net app is run?

 

[Tom Shelton]

But then, how can we write apps more efficiently when even a basic
form with just a single push-button takes several seconds, while its
VB Classic takes less than a second?

Again, your talking about startup times. You snipped out the part right
after, where I said startup times were an issue... Also, I'd like to
know what hardware your running on that takes several seconds to load a
simple form? Even on my old 1.3 GHz AMD system, it only takes between 1
and 2 seconds....

Still, there are things you can do...

The biggest is to try and avoid as much work as possible durring
initialization. Why? Because .NET only loads satalite assemblies as
needed - basically the first time a type in them is referenced. The
initial load of an assembly (really any dll) is expensive, because it
has to be read from disk, and then mapped into the processes address
space - and if there any address collisions, then it has to be relocated
until free space is found. You can minimize this by making sure your
rebase all of your custom assemblies. So, the smart thing to do here is
basically delay as much intialization as you can - maybe moving it to
background threads once your app has started up.

You can also run a profiler on your application, to find out where it's
spending it's time durring startup. Obviously, you can't do anything
about framework stuff, but you might find that some of the problem is in
code that you can do something about.

Besides compiling the .Net app before distributing it to customers and
avoid the JIT kicking-in, Isn't it possible to load .Net stuff at
boot-time, so it's available in RAM whenever a .Net app is run?

The framework is not in ram, it's in disk cache. I suppose you could
write a app that just started and exited and made it run at startup

 

[kimiraikkonen]

The framework is not in ram, it's in disk cache. I suppose you could
write a app that just started and exited and made it run at startup

I tried this and did a simple msgbox-based startup app and put into
Windows's startup registry(you know the path) to have framework loaded
into disk cache. Then the next execution of "this" startup app is done
in less than a second, almost instantly. But other .NET apps is still
opened in approx. 3 seconds to see the first form if i use this
putting a simple .NET app into startup technique There become an
accelearation quite visible but not as much as classic apps(like
VB6's).

Anyway, it's explict that .NET framework based apps requires very good
hardware especially big disk buffer and high-speed memory not to be
disturbed due to startup latency.

Thanks.

 

[Teemu]

Anyway, it's explict that .NET framework based apps requires very good
hardware especially big disk buffer and high-speed memory not to be
disturbed due to startup latency.

Try this:

http://technet.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

It's located in here (for example):

C:\Windows\Microsoft.NET\Framework\v2.0.50727

-Teemu

 

[Chris Mullins [MVP - C#]]

What you're describing is pretty well documented, and is (unfortunatly) the
reality with .Net.

The commonly used names for the problems are "Cold Start" and "Warm Start".
There's a good overview of the problem, and a fairly detailed set of things
you can do to improve you app at:
http://msdn.microsoft.com/msdnmag/issues/06/02/CLRInsideOut/default.aspx

I personally find the best thing is an unmanaged splash screen. A cheap and
easy to integrate product is:
http://www.quicksplash.net/