 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / March 2008how to decrease the cpu usage
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 > Hello everyone. > [quoted text clipped - 16 lines] > 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. > ^^....help me '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. lightdoll wrote: > Hello everyone. > [quoted text clipped - 16 lines] > 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. > ^^....help me > '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.)  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet World class .NET training in the UK: http://iterativetraining.co.uk "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.) > "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: I agree with much of what you say. "Reasonable" to me is a balancing act. Jon On Mar 10, 11:24 am, "Jon" <.> wrote: > "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 > '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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.