Page faults increase forever, keep memory allocated instead of alloc/free each time

[GoogleCodeExporter]

Looking at task manager, the OHM process has ever-increasing page faults which 
looks like an alloc/free happening each polling cycle.  If you could alloc once 
and never free, that would cut the resource usage as each page fault requires 
zeroing a fresh page.

Original issue reported on code.google.com by old...@ymail.com on 8 Jun 2011 at 5:51

[GoogleCodeExporter]

Thank you for reporting this, I will have to look into it in more detail. One 
location that causes page faults is 

OpenHardwareMonitor.GUI.GadgetWindow.Update

Also redrawing the TreeViewAdv (triggered by treeView.Invalidate) causes page 
faults.

The hardware reading itself seems not to produce any page faults.

Original comment by moel.mich on 19 Jun 2011 at 10:15

• Changed state: Accepted

[GoogleCodeExporter]

Revision r339 should fix the problem in 
OpenHardwareMonitor.GUI.GadgetWindow.Update. Now the pages faults only increase 
constantly when the main window is shown. Locating (and fixing) the TreeViewAdv 
related problems will require more work.

Original comment by moel.mich on 22 Jun 2011 at 10:38

• Changed state: Started

[GoogleCodeExporter]

I have taken a look at the reason why treeView.Invalidate and 
plotPanel.Invalidate cause many page faults. Most page faults are not caused by 
the actual painting of the plots or the tree view, but by the double buffering. 
I have enabled the double buffering support from Windows Forms for both 
components in order to avoid flicker. It seems like Microsoft implemented 
double buffering in a bit a strange way. Probably allocating and disposing the 
second buffer for every paint event.

Microsoft thinks we should not be concerned by this, as it is "by design".

http://connect.microsoft.com/VisualStudio/feedback/details/96081/cvery-serious-p
roblem-in-gdi-or-net

They do also not intend to fix this in the Windows Forms implementation. So I 
do not really see a way to fix it without rewriting large parts of Windows 
Forms.

The problem in the gadget is fixed, and the application does no longer create 
page faults at a high rate when it is running in the background (main window 
not visible). I think this is good enough for now, unless someone comes up with 
good arguments what to do differently.

Original comment by moel.mich on 23 Jun 2011 at 8:41

• Changed state: Fixed

[GoogleCodeExporter]

There even is an option to configure the memory management for the Windows 
Forms double buffering. I have changed it now with revision r341, so that it no 
longer allocates/disposes new buffers for each draw call. This now removes the 
excessive page faults even when the GUI is visible.

Original comment by moel.mich on 25 Jun 2011 at 2:48

[GoogleCodeExporter]

Thanks -- eagerly awaiting a new build to try out this fix.

Original comment by old...@ymail.com on 14 Sep 2011 at 3:04