Does anyone have millions and millions of soft page faults when running Ninja ?

I have gazillions of them.

sniffy 

Does anyone have millions and millions of soft page faults when running Ninja ? I have gazillions of them.

Depends more on the working set size and the PF Delta (i.e. rate), if the baseline PF Delta is in the 2-5k range during normal use for a 500Mb footprint I'd say that's very normal. PF Delta on mine will jump to 12-15k when I switch workspaces but its still instant.

All OO type software programs tend to destroy low-level caches, hence the desire for heaps of DDR3. Not really a worry given the level of functionality we get in exchange, only a real worry if you get into hard page fault territory, then you have a system dog on your hands...

So for all those thousands who are secretly dying to know ...

The background is that I have a spawned Form that creates price bars/other objects and is drawn and updated by a multi-layered graphics process that uses Bitmaps for buffers. This gives me double buffering with the drawing taking place in memory, then the painting of only those elements that have changed taking place in the Paint event handler.

However, I had left in place in my Form constructor, the setStyle instruction to use .Net double buffering. (I think the default for Forms is double buffering). So I changed that to not use double buffering ( I was already doing it manually through the Bitmap buffer after all).

Here is my complete setStyle list:

this.DoubleBuffered = false;
this.SetStyle(ControlStyles.SupportsTransparentBackColor, true);
this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);
this.SetStyle(ControlStyles.OptimizedDoubleBuffer, false);
this.SetStyle(ControlStyles.UserPaint, true);
this.SetStyle(ControlStyles.ResizeRedraw, true);

Getting rid of the .Net double buffering reduced my soft page faults PFDelta from a background level of circa 450 with quite frequent peaks of 6/7 K and even up to 10-20K, by more than half. By double buffering x double buffering I presume that I was probably setting up a nice chain of unnecessary page faults.

Has there been any noticeable performance degradation ? None whatsover. The Bitmap double buffering and other anti-flicker options in the setStyles are clearly doing their job.

Not that there was any apparent visual issue before this change other than the unsettling number of soft page faults. However when you are waiting for confirmation of a fill or whatever, every little edge can obviously be very valuable.

In the process of trying to track down the reasons for these page faults I also noticed that I was allocating the Bitmaps in a way that didn't make sense, and sorting this out seems to have reduced the page fault regime further, and sorted a very small Dispose issue.

I also tried different options in the Bitmap allocation statement. I found that there was no apparent effect either on perceived graphics performance, or on the page fault annoyance. I currently use this:

Bitmap newBitmap5 = new Bitmap(rightPanel.Width, rightPanel.Height, PixelFormat.Format32bppPArgb);

So where am I now?

I have a baseline PFDelta of about 300 with peaks/spikes up to about 1K. Perceived graphics performance is still excellent with not a sign of flicker. Reducing the number of soft page faults was not the objective, gaining an understanding of why they seemed so high was.