Control. DoubleBuffer = true causes a lot soft page faults

[tbatwork828]

Related to my other post on Graphics.FillRectangle and a lot of page
faults caused by this call...

We determine that when Control.DoubleBuffer=true to avoid the flicker
effect, Graphics.FillRectangle causes a lot of soft page faults - order
of 700/sec and more... When Control.DoubleBuffer=false, we have no page
faults at all - 0/sec.

Has anyone seen this behavior and how did they resolve it...? What are
our options...? Does "OptimizedDoubleBuffer" do anything in .NET
2.0...?

Also - soft page faults are not an issue in a general sense, but if
they average around 1500/sec like they do for our app and they never
even get close to zero at all during the whole test, and they also
relate to one method Graphics.FillRectangle and
Control.DoubleBuffer=true, then this is definitely something to get
concerned about. From the tool we used to monitor the page faults done
by Graphics.FillRectangle, it appears it page faults every time the
method is invoked - through our Control.Render calls with
Control.DoubleBuffer=true.

thx

 

[Nicholas Paldino [.NET/C# MVP]]

Not to be blunt, but you aren't exactly indicating that this is
impacting your performance in a bad way. You just have this statement that
you have a good number of soft page faults, and imply that it is a problem,
which you need to fix.

Is the application not performing correctly, or not performant as a
result?

It's not that I think you are wrong, but there are a good number of
people who post to the groups with questions regarding high numbers in
certain things (page faults, memory usage in task manager) and associate
that with something wrong with the program. This isn't always the case.
I'll admit that yes, you should understand what is going on in your program
(to what degree is debatable), but at the same time, if you don't have any
negative effects, or even postulate what negative effects you might have as
a result of what you are observing, then I question the reasons for wanting
to address the issue.

Can you clarify what you think might happen, or is happening as a
result?

 

[Willy Denoyette [MVP]]

Related to my other post on Graphics.FillRectangle and a lot of page
faults caused by this call...

We determine that when Control.DoubleBuffer=true to avoid the flicker
effect, Graphics.FillRectangle causes a lot of soft page faults - order
of 700/sec and more... When Control.DoubleBuffer=false, we have no page
faults at all - 0/sec.

Has anyone seen this behavior and how did they resolve it...? What are
our options...? Does "OptimizedDoubleBuffer" do anything in .NET
2.0...?

Also - soft page faults are not an issue in a general sense, but if
they average around 1500/sec like they do for our app and they never
even get close to zero at all during the whole test, and they also
relate to one method Graphics.FillRectangle and
Control.DoubleBuffer=true, then this is definitely something to get
concerned about. From the tool we used to monitor the page faults done
by Graphics.FillRectangle, it appears it page faults every time the
method is invoked - through our Control.Render calls with
Control.DoubleBuffer=true.

thx

A "Soft" page fault occurs each time there is transition between the
"transition" lists (like the standby page list, modified page list, Free
page list etc...) and the process(es) working set. A process that
reserves/commits a large number of pages will incur a lot of soft page
faults. A graphics application (I would never use .NET to author one) might
consume a lot of memory when large pictures are brought in into the WS,
especially when double buffering is used.
So, if you really want to reduce the Soft faults (but I don't see any
reason, unless they escalate to hard faults), you'll have to consume less
memory, that means you'll have to turn off double buffering or reduce the
picture size.


Willy.

 

[tbatwork828]

Avg of 1500 page faults/sec for a control with DoubleBuffering=true is
a lot to everyone even if they are soft PFs -- page =4Kb - so we can do
the math so to speak how much we are soft page faulting ... When
doublebuffer=false, the page faults are down to 0/sec. Since we all
agree soft page faults are not a bad thing - I agree they are not, but
only in lower numbers than what we are getting - we are consistently
above 1000/sec and never even come up to 0 when doublebuffer=tue. I
would view any app in Task Manager- PF Delta and I would challenge to
come up with the numbers we are having. Every time we need to render a
control with this setting on, and when a soft page faults occurs, means
less time requests are spent on the processor executing, as memory is
being searched for in order for the request to be sent to the
processor. With the number of SPFs we have, that to me can add up, and
although in ms's, I would hate to drop this issue just on the account
of SPFs not being such a bad thing. Although users do not see any
performance difference (you are correct), this is a concern and needs
to be addressed. We figured out that a call to .FillRectangle with
double buffering on causes 160 soft page faults/sec --every time--
..FillRectangle is executed - so it page faults every time. This either
sounds like an inefficient code to me or smth we are not being told.

Don't know about everyone - but if you know of workarounds or anything
else to point us how to fix the problem - I would love to hear it. I
don't think that argument soft page faults are not bad would work in
this case as that is hardlu something I can use to explain this
behavior. BTW, we are logging a bug to Microsoft to hear their opinion
as well.

 

[Willy Denoyette [MVP]]

Avg of 1500 page faults/sec for a control with DoubleBuffering=true is
a lot to everyone even if they are soft PFs -- page =4Kb - so we can do
the math so to speak how much we are soft page faulting ... When
doublebuffer=false, the page faults are down to 0/sec. Since we all
agree soft page faults are not a bad thing - I agree they are not, but
only in lower numbers than what we are getting - we are consistently
above 1000/sec and never even come up to 0 when doublebuffer=tue. I
would view any app in Task Manager- PF Delta and I would challenge to
come up with the numbers we are having. Every time we need to render a
control with this setting on, and when a soft page faults occurs, means
less time requests are spent on the processor executing, as memory is
being searched for in order for the request to be sent to the
processor. With the number of SPFs we have, that to me can add up, and
although in ms's, I would hate to drop this issue just on the account
of SPFs not being such a bad thing. Although users do not see any
performance difference (you are correct), this is a concern and needs
to be addressed. We figured out that a call to .FillRectangle with
double buffering on causes 160 soft page faults/sec --every time--
.FillRectangle is executed - so it page faults every time. This either
sounds like an inefficient code to me or smth we are not being told.

Don't know about everyone - but if you know of workarounds or anything
else to point us how to fix the problem - I would love to hear it. I
don't think that argument soft page faults are not bad would work in
this case as that is hardlu something I can use to explain this
behavior. BTW, we are logging a bug to Microsoft to hear their opinion
as well.

Please post your code or at least a repro that illustrates the issue, the
point is that I can't see how you know that FillRectangle is causing PF's,
each FillRectangle is followed by a Redraw I guess (which is causing PF's,
just minimize/maximize Explorer for instance and watch the PF's delta)).
Note also that, as I said before, that the number of PF's depend on the
number and the size of the input images (bitmap or whatever) not the size of
the drawing rectangle.


Willy.