How can I avoid the huge number of soft page faults generated by my C# .NET app?

Question

I'm profiling a C# .NET WinForms application and i have noticed that it generates millions of soft page faults and keep increasing during the work ...

I know that in .NET the number of pages fault that an application generates is usually high, but millions of page faults seems too much... Seems that the application triggered a race condition with the GC, is it possible ?

Are there some known ill designed piece of code that can lead to this situation ? If not in the code is there some hidden settings of the .NET framework that can reduce the number of page faults ?

The generation of an increasingly high number of soft page faults can be avoided ?

Belinda

Why do you care? How much time are these faults taking? Do you understand that soft faults don't read from the disk? – Yungyunick

Yes i know that soft faults don't read disk, but the number is huge and keep increasing ... Is it normal ? I don't think it is a normal behaviour . – Belinda

The normal behavior is to ignore random numbers and to concentrate on solving problems. Is this a problem, or just a random number you happen to have observed? – Yungyunick

It seems not affecting performance, i'm not sure. However just curiosity ... – Belinda

Soft page fault, means it's there, but not available. Shared memory for instance. More trouble than it's worth to try and address I should think and you'll quite probably lower performamnce by having a go. Idea is to free up memory, start hanging on to it and ... – Column

OTHER running applications could be using a lot of memory and causing pages to be discarded faster than "normal". – Hollowell

If it ain't broke don't fix it – Nickens

yes, all your considerations are reasonable and i thank for that, but i wish to understand why the number of page fault is so high... – Belinda

Answer 1

I'd really recommends leaving this thing alone if it is not a problem. If you have performance problems though - Try and isolate the code that generates the most page faults - It is probably somewhere that you're using a large memory footprint object.

Try to keep your "unsafe" code as isolated and simple as possible, ie. encapsulate all the unsafe code in a class or function. Keep in mind that messing the .NET GC could lead to complications mostly unneeded.

Check this article for a bit of unsafe introduction (It's a bit old but still true): http://www.codeproject.com/KB/cs/unsafe_prog.aspx

Also, you could raise the time until the GC collects, this might help

Kanpur