I’m running Windows Vista and Visual Studio 2010, using .NET 4.
2 GB of RAM and about 800 MB free.
I create a Windows Form application and add no code to it. Just compile it in release mode, close Visual Studio and start the application. If I look in task manager the application generated 3500 page faults for just starting and doing nothing.
If I create a console application and just add a Console.ReadLine(); to keep it open it generates 1500 page faults.
Is that normal behaviour for .NET? These numbers seem ridiculously high to me.
You have to understand that there’s more code to a .NET application than just the code you wrote. It has to load the assembly, parse it, compile it, execute it, then load in various support libraries, etc.. (some of which may require similar parsing, compiling, etc..), and all of those things create page faults. 3,500 is not that many page faults in the grand scheme of things.
As an example, I tried out a few “simple” console applications. More, run from a console, generates 750 page faults, and this is a pretty tiny application that does little more than echo from one input to the other. It’s written in C, a language that is not garbage collected, doesn’t have a virtual machine, or a big runtime library that has to come with it (it’s statically linked, so it’s not depending on a runtime).
Given all that .NET does, a single line console application that just does a ReadLine using only 1,500 page faults seems quite good.
I’m not even sure why you care about page faults. Perhaps you are coming from a platform where page faults are a bad thing. In Windows, processes are “page backed”, which means that the OS memory maps an executable, and then demand loads pages as needed (this includes shared libraries, as well as the executable itself, icons, images, all kinds of things). Each of those pages generate a page fault when the OS needs to load them into memory. That’s normal, and that’s the way the OS works.