Are MFC Timer(s) bad for performance in large projects (Vc++)
-
Hey out there, i'm heared that the use of timers in large projects is bad for performace. So is this true? I'm wondering, because i have done a new control using VC++/MFC and i use one timer in there. The timer only is created and the first time it's called i terminate it. Now someone said to me that i sould use ::GetTickCount() instead and save the first value and compare it again and again. It look more performance hungry than my timer solution. So what's your oppinion? Please don't answer something like i should do a test, i haven't so much time to test such things. And please answer only real facts and not only stuff like "i like timers more because i like it more" or "i like the TickCount solution more". Hope for a good discussion :)
-
Hey out there, i'm heared that the use of timers in large projects is bad for performace. So is this true? I'm wondering, because i have done a new control using VC++/MFC and i use one timer in there. The timer only is created and the first time it's called i terminate it. Now someone said to me that i sould use ::GetTickCount() instead and save the first value and compare it again and again. It look more performance hungry than my timer solution. So what's your oppinion? Please don't answer something like i should do a test, i haven't so much time to test such things. And please answer only real facts and not only stuff like "i like timers more because i like it more" or "i like the TickCount solution more". Hope for a good discussion :)
I think it largely depends on specific circumstances... for example, I've used timers to update fields that change at extremely high-rates. Under those circumstances, timers were actually a HUGE improvement on an old system that updated UI fields as often as new data was available. So my opinion is... use what works for you.
-
Hey out there, i'm heared that the use of timers in large projects is bad for performace. So is this true? I'm wondering, because i have done a new control using VC++/MFC and i use one timer in there. The timer only is created and the first time it's called i terminate it. Now someone said to me that i sould use ::GetTickCount() instead and save the first value and compare it again and again. It look more performance hungry than my timer solution. So what's your oppinion? Please don't answer something like i should do a test, i haven't so much time to test such things. And please answer only real facts and not only stuff like "i like timers more because i like it more" or "i like the TickCount solution more". Hope for a good discussion :)
Using anything in an inappropriate way may be bad for performance. Using it correctly shouldn't. Your question isn't so much about timers being bad in general, but about the proper use of one. The size of the application has nothing got to do with it at all. As for our opinion: it's impossile to tell if you're not more specific. It's ironic how you're asking for specific answers, yet fail to offer the minimal information required to answer the question properly. There are plenty of timer interfaces that you might use, you didn't specify yours. As for
GetTickCount, that is a bad way to measure performance since it only checks the system time, not the time your application uses: if other applications are running at the same time and slowing the whole system down, you'll get much higher values! If your purpose is to measure program performance, a more suitable function to use would be clock()[^]GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
Using anything in an inappropriate way may be bad for performance. Using it correctly shouldn't. Your question isn't so much about timers being bad in general, but about the proper use of one. The size of the application has nothing got to do with it at all. As for our opinion: it's impossile to tell if you're not more specific. It's ironic how you're asking for specific answers, yet fail to offer the minimal information required to answer the question properly. There are plenty of timer interfaces that you might use, you didn't specify yours. As for
GetTickCount, that is a bad way to measure performance since it only checks the system time, not the time your application uses: if other applications are running at the same time and slowing the whole system down, you'll get much higher values! If your purpose is to measure program performance, a more suitable function to use would be clock()[^]GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
Stefan_Lang wrote:
Using anything in an inappropriate way may be bad for performance. Using it correctly shouldn't.
I like that... :thumbsup:
-
Using anything in an inappropriate way may be bad for performance. Using it correctly shouldn't. Your question isn't so much about timers being bad in general, but about the proper use of one. The size of the application has nothing got to do with it at all. As for our opinion: it's impossile to tell if you're not more specific. It's ironic how you're asking for specific answers, yet fail to offer the minimal information required to answer the question properly. There are plenty of timer interfaces that you might use, you didn't specify yours. As for
GetTickCount, that is a bad way to measure performance since it only checks the system time, not the time your application uses: if other applications are running at the same time and slowing the whole system down, you'll get much higher values! If your purpose is to measure program performance, a more suitable function to use would be clock()[^]GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
I'd like too. Using it correctly, the timer has a good performance. Sometimes, GetTickCount is a good solution, but it wastes too many cpu time to do this. On the other hand, Timer provide a good way to let you know when times out, and you can do anything in the period.
-
I'd like too. Using it correctly, the timer has a good performance. Sometimes, GetTickCount is a good solution, but it wastes too many cpu time to do this. On the other hand, Timer provide a good way to let you know when times out, and you can do anything in the period.
What are you talking about? Timers do not have bad performance! Timers don't waste CPU! All they do is read some hardware register. We're talking nanoseconds here! Keep in mind that almost all timer functions can measure at a resolution of only about 20-50ms at best, even though the unit typically used for the result value is in ms. Calling them more often then 100 times a second is therefore utterly pointless and stupid. Calling them less often will not result in any performance loss that you are able to measure!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
What are you talking about? Timers do not have bad performance! Timers don't waste CPU! All they do is read some hardware register. We're talking nanoseconds here! Keep in mind that almost all timer functions can measure at a resolution of only about 20-50ms at best, even though the unit typically used for the result value is in ms. Calling them more often then 100 times a second is therefore utterly pointless and stupid. Calling them less often will not result in any performance loss that you are able to measure!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
I am so sorry about you misunderstood my words, my English is very poor! :) I agree with you about timers don't waste CPU, because it provides a way that can be waited, when times out, the callback functions is invoked. About nanoseconds measure, clock() maybe right, but windows gives high-precision clock to us for API, it is QueryPerformanceFrequency(). But I think C3D1 just want to know which way is more performance in GetTickCount and Timer. I think you are a good guys, Can I make friends with you ? ;P
-
I am so sorry about you misunderstood my words, my English is very poor! :) I agree with you about timers don't waste CPU, because it provides a way that can be waited, when times out, the callback functions is invoked. About nanoseconds measure, clock() maybe right, but windows gives high-precision clock to us for API, it is QueryPerformanceFrequency(). But I think C3D1 just want to know which way is more performance in GetTickCount and Timer. I think you are a good guys, Can I make friends with you ? ;P
I understand that english is not your first language - no need to apologize. As for "waiting" or "callback", I don't see the OP asking about that at all. If his question were about waiting, he should use Sleep()[^] , not timer functions. I understand the question as one about program performance, i. e. the CPU time it uses. Since the indicated functions don't measure CPU time, their properties are irrelevant. That is why I suggested clock()[^] . You are correct that it it possible to use higher precision timers. However, most of the time the standard timers are sufficiently accurate for fixing performance issues. That said, the OP suggested comparing times "again and again", implying constant polling - and that doesn't make sense at all! Therefore I made my initial statement about 'inappropriate use' of timers. There is one other possible scenario that the OP may be referring to: waiting for an operation to finish, but not for longer than a predetermined amount of time. If that is the case, I'd suggest using WaitForMultipleObjects()[^] .
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
I understand that english is not your first language - no need to apologize. As for "waiting" or "callback", I don't see the OP asking about that at all. If his question were about waiting, he should use Sleep()[^] , not timer functions. I understand the question as one about program performance, i. e. the CPU time it uses. Since the indicated functions don't measure CPU time, their properties are irrelevant. That is why I suggested clock()[^] . You are correct that it it possible to use higher precision timers. However, most of the time the standard timers are sufficiently accurate for fixing performance issues. That said, the OP suggested comparing times "again and again", implying constant polling - and that doesn't make sense at all! Therefore I made my initial statement about 'inappropriate use' of timers. There is one other possible scenario that the OP may be referring to: waiting for an operation to finish, but not for longer than a predetermined amount of time. If that is the case, I'd suggest using WaitForMultipleObjects()[^] .
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
Sorry, maybe i misunderstood the OP's question. I understand the question as the OP want to delay executing. You are right, if he want to waiting, he should use Sleep. Through this, I think you are a good programmer who understand OS well, nice to meet you ! There is another question, sometimes you just want to delay executing, Sleep, Timers, or GetTickCount all is right. Sleep don't waste any CPU time. GetTickCount does it. But sometimes, free loop just like GetTickCount is a performance way to wait a predetermined a mount of time, like SpinLock. What do you think about it.
-
Sorry, maybe i misunderstood the OP's question. I understand the question as the OP want to delay executing. You are right, if he want to waiting, he should use Sleep. Through this, I think you are a good programmer who understand OS well, nice to meet you ! There is another question, sometimes you just want to delay executing, Sleep, Timers, or GetTickCount all is right. Sleep don't waste any CPU time. GetTickCount does it. But sometimes, free loop just like GetTickCount is a performance way to wait a predetermined a mount of time, like SpinLock. What do you think about it.
No! Don't use GetTickCount if all you want to do is wait. Ever. What it amounts to is a busy loop that eats the entire CPU time as it is repeated hundreds of millions of times per second! You're slowing other programs by doing that, because one CPU core will be completely locked by your program! If your CPU only has one core, the Computer will freeze! If your program has any GUI parts that the user interacts with, these will freeze also. A user sitting in front of the computer may think the program is crashed, and restart it. Not to mention that a modern OS has many tasks running in the background that you are preventing from working! Do not needlessly eat CPU time!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
-
No! Don't use GetTickCount if all you want to do is wait. Ever. What it amounts to is a busy loop that eats the entire CPU time as it is repeated hundreds of millions of times per second! You're slowing other programs by doing that, because one CPU core will be completely locked by your program! If your CPU only has one core, the Computer will freeze! If your program has any GUI parts that the user interacts with, these will freeze also. A user sitting in front of the computer may think the program is crashed, and restart it. Not to mention that a modern OS has many tasks running in the background that you are preventing from working! Do not needlessly eat CPU time!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
Yeah, I can't agree with you any more ! Sometimes, i should delay a short time precisely, I think free loop is useful. just like wait some uart data in real OS. May I get your email, i just want to contact with you frequently! :)