.NET Application Startup Times

[Ralf Maximus]

General question for .NET experts...

Why do .NET applications (programs compiled using Visual Studio 2003 or newer) take so frikkin long to load?

And what the heck is with all the disk activity?  I have some very tiny utilities that take 15-20 seconds to start and run the disk drive like a defragger.  More complicated apps using a different compiler boot up faster.

So what's going on behind the scenes?  Or have I just been unlucky enough to stumble across a few unoptimized .NET apps?

[tinjaw]

.NET is a common library, and a big one at that. So the first time you load an application that needs it it loads the whole thing. Every application you load after that should load quickly as they share. This is very similar to booting up the operating system as it loads all the drivers.

[tinjaw]

Oh. And if you are curious, fire up Sysinternals/Microsoft Process Explorer. The default is to highlight all of the applications that are sharing the .NET framework. I'm packing up to leave work. Maybe somebody can post a screenie, otherwise I will try to post one when I get settled in at home tonight.

[f0dder]

The first time you run a dotNET app after system bootup, you take a huge penalty for getting the dotNET subsystem started. After this, iirc, it stays loaded.

Also, the first time you run a dotNET app, regardles of whether you have the dotNET runtime loaded, you get some JITing penalty.

After that, it's not all that bad, although dotNET binaries are heavier than native code.

[tinjaw]

Here are those screenies.

Program is Sysinternals' Process Explorer.

[attachimg=#1][/attachimg]
[attachthumb=#2][/attachthumb]

[Ehtyar]

You also need to take into account run-time compiling by dotnet assemblies. I am unsure of the circumstances under which this takes place, but i do know it is only required the first time a .net application is run and compilation takes a LOT of resources, particularly .net. This does not afflict all .net applications.

Ehtyar.

[tinjaw]

Ehtyar,  please excuse me if I am being presumptuous, but you may not be the only one who didn't parse f0dder's statement... "you get some JITing penalty." JIT is Just In Time, which is what you are describing. So f0dder (who is a much wiser man that I and often assumes all readers will understand his lingo) was describing that there is this small penalty.

[Ehtyar]

Given the lack of context, i did indeed skip over that comment. I actually assumed he meant JIT debugging as in perhaps the .net framework did some setup for JIT debugging of itself. Thank you for the explanation.

Ehtyar.

[Ralf Maximus]

Thanks for the explanation, guys.  I turned on the .NET highlighting in PE and it turns out I do already have some .NET apps running in the background at all times.  So what I'm bitching about appears to be the JIT recompiling behavior of whatever new apps I launch.

Surprising, since I'd assumed the newer compiler would be more efficient than what's come before.  But maybe Microsoft's metric for efficiency nowadays is, "how much money can we squeeze out of developers for new tools?"

[f0dder]

The JITter is supposed to cache results, though, so you should get a first-time JIT penalty, and then not so much on subsequent runs (although dynamic JITing based on runtime profiling is also supposed to be done - but I dunno if this is just "we want it to" or "we are doing it already" ).

Iirc. there's a "compile [dotNET] assembly to nativer code" tool shipped with the framework, but I can't for the life of me remember it's name. Might help you out somewhat, worth a search anyway.

[hamm4915]

I believe it is called Native Image Generator and the command is ngen.exe

[f0dder]

I believe it is called Native Image Generator and the command is ngen.exe

-hamm4915 (November 27, 2007, 11:21 AM)

That was it, thank you