how to decrease the cpu usage

[lightdoll]

Hello everyone.

i want to know how to decrease the cpu usage in my program.

i have to update quickly many data on gui,

so i tried to decrease the cpu usage on gui but i couldn't solve the problem.

i found the code with probloem why the cpu usage increased by debug..

Rectangle invalidateRect = new Rectangle(_detailVisibleRect.Left,
_detailVisibleRect.Top + item.Y - _vScrollBar.Value, _detailRect.Width,
item.Height);
this.Invalidate(invalidateRect);

if i don't call this code, then the cpu usage is ok,

but after i call this code, the cpu usage of my problem become between 10 ~
15%.

could you tell me how to solve this kind of problem if you have to update
many data
on GUI as fast as possible.

^^....help me

 

[Ben Voigt [C++ MVP]]

Hello everyone.

i want to know how to decrease the cpu usage in my program.

i have to update quickly many data on gui,

so i tried to decrease the cpu usage on gui but i couldn't solve the
problem.

i found the code with probloem why the cpu usage increased by debug..

Rectangle invalidateRect = new Rectangle(_detailVisibleRect.Left,
_detailVisibleRect.Top + item.Y - _vScrollBar.Value,
_detailRect.Width, item.Height);
this.Invalidate(invalidateRect);

if i don't call this code, then the cpu usage is ok,

but after i call this code, the cpu usage of my problem become
between 10 ~ 15%.

Well, that's what causes the screen to redraw, so I would expect it to use
some CPU. Maybe it doesn't need as much as it currently uses though.

could you tell me how to solve this kind of problem if you have to
update many data
on GUI as fast as possible.

First thing that will help is to recognize that "as fast as possible" isn't
needed. Just "as fast as is perceptible to the user". So, for example, you
could limit animation to 30/second or data updates to 5/second and the user
won't notice the delay.

Next, although your code does a great job of defining the update region
correctly, if your paint code doesn't use the update region, there's no
benefit.

You might simply try this:

Add a timer with a period of 150ms.
Change the invalidate code to simply set a boolean dirty flag.
In the timer callback, if the dirty flag is set, invalidate the whole window
and clear the flag. (If you have multiple threads, you should use
Interlocked.Exchange to clear the boolean flag and give you the old value)

This will probably decrease the number of repaints dramatically and
therefore save you a lot of CPU.

 

[Jon]

'First thing that will help is to recognize that "as fast as possible" isn't needed. Just "as fast
as is perceptible to the user".'

Ben: that can be pretty difficult to define, since you don't always know how powerful the end user's
computer is.

Hello everyone.

i want to know how to decrease the cpu usage in my program.

i have to update quickly many data on gui,

so i tried to decrease the cpu usage on gui but i couldn't solve the
problem.

i found the code with probloem why the cpu usage increased by debug..

Rectangle invalidateRect = new Rectangle(_detailVisibleRect.Left,
_detailVisibleRect.Top + item.Y - _vScrollBar.Value,
_detailRect.Width, item.Height);
this.Invalidate(invalidateRect);

if i don't call this code, then the cpu usage is ok,

but after i call this code, the cpu usage of my problem become
between 10 ~ 15%.

Well, that's what causes the screen to redraw, so I would expect it to use
some CPU. Maybe it doesn't need as much as it currently uses though.

could you tell me how to solve this kind of problem if you have to
update many data
on GUI as fast as possible.

First thing that will help is to recognize that "as fast as possible" isn't
needed. Just "as fast as is perceptible to the user". So, for example, you
could limit animation to 30/second or data updates to 5/second and the user
won't notice the delay.

Next, although your code does a great job of defining the update region
correctly, if your paint code doesn't use the update region, there's no
benefit.

You might simply try this:

Add a timer with a period of 150ms.
Change the invalidate code to simply set a boolean dirty flag.
In the timer callback, if the dirty flag is set, invalidate the whole window
and clear the flag. (If you have multiple threads, you should use
Interlocked.Exchange to clear the boolean flag and give you the old value)

This will probably decrease the number of repaints dramatically and
therefore save you a lot of CPU.

 

[Jon Skeet [C# MVP]]

'First thing that will help is to recognize that "as fast as
possible" isn't needed. Just "as fast as is perceptible to the
user".'

Ben: that can be pretty difficult to define, since you don't always
know how powerful the end user's computer is.

Your requirements should include a minimum spec at which the client
responds reasonably.

It's certainly easier to define that than it is to optimise *forever*.
(There's always going to be something you can do to squeeze an extra
0.0001% of performance out of a system - but it's not a useful thing to
do.)

 

[Jon]

"Your requirements should include a minimum spec at which the client responds reasonably."

Even then it can be difficult to predict how fast that system is. Processor speed and memory size
and the other commonly mentioned parameters don't always give the full picture - two apparently
identical PCs can perform differently. You may not even have such a PC to test on.

I agree with your comment about 0.00001%, but I get the feeling that some programmers might just
check to ensure that it's fast enough on their development PC, and not consider that very worthwhile
speed improvements on slower PCs can still be made by making code changes.

I tend to mentally convert phases like "as fast as possible" into "as fast as is reasonably
possible".


Your requirements should include a minimum spec at which the client
responds reasonably.

It's certainly easier to define that than it is to optimise *forever*.
(There's always going to be something you can do to squeeze an extra
0.0001% of performance out of a system - but it's not a useful thing to
do.)

 

[Jon Skeet [C# MVP]]

"Your requirements should include a minimum spec at which the client responds reasonably."

Even then it can be difficult to predict how fast that system is. Processor speed and memory size
and the other commonly mentioned parameters don't always give the full picture - two apparently
identical PCs can perform differently. You may not even have such a PC to test on.

While it's true that there are lots of factors to consider, it seems
fairly pointless making performance improvements if you've got no idea
when you're "done". I would say it's important practice to have a test
machine somewhere which is used as a lowest common denominator. It
won't cover *all* bases, but it's a good starting point.

I agree with your comment about 0.00001%, but I get the feeling that some programmers might just
check to ensure that it's fast enough on their development PC, and not consider that very
worthwhile speed improvements on slower PCs can still be made by making code changes.

On the other hand, other programmers tend to waste time on micro-
optimisations which will have no useful effect, and make code harder
to maintain.

I tend to mentally convert phases like "as fast as possible" into "as fast as is reasonably
possible".

But the definition of "reasonably" depends on who you ask, and without
both measurement and a goal, you're likely to waste time optimising
code that isn't really a problem to anyone.

Jon

 

[Jon]

Jon: I agree with much of what you say. "Reasonable" to me is a balancing act.

Jon

"Your requirements should include a minimum spec at which the client responds reasonably."

Even then it can be difficult to predict how fast that system is. Processor speed and memory size
and the other commonly mentioned parameters don't always give the full picture - two apparently
identical PCs can perform differently. You may not even have such a PC to test on.

While it's true that there are lots of factors to consider, it seems
fairly pointless making performance improvements if you've got no idea
when you're "done". I would say it's important practice to have a test
machine somewhere which is used as a lowest common denominator. It
won't cover *all* bases, but it's a good starting point.

I agree with your comment about 0.00001%, but I get the feeling that some programmers might just
check to ensure that it's fast enough on their development PC, and not consider that very
worthwhile speed improvements on slower PCs can still be made by making code changes.

On the other hand, other programmers tend to waste time on micro-
optimisations which will have no useful effect, and make code harder
to maintain.

I tend to mentally convert phases like "as fast as possible" into "as fast as is reasonably
possible".

But the definition of "reasonably" depends on who you ask, and without
both measurement and a goal, you're likely to waste time optimising
code that isn't really a problem to anyone.

Jon

 

[Ben Voigt [C++ MVP]]

'First thing that will help is to recognize that "as fast as
possible" isn't needed. Just "as fast as is perceptible to the
user".'

Ben: that can be pretty difficult to define, since you don't always
know how powerful the end user's computer is.

The maximum perceptible refresh rate is not computer dependent.

The CPU usage needed to attain that frame rate is.