Optimizing
-
I need a few c++ code optimizing tips. Anybody knows where I can find good ones? regards hint_54
The first rule is to measure first. You need to pinpoint a specific piece of code that is slower then could be and is worth the trouble of changing (you want some bang for your buck). It is a well known fact that when developers try to guess they get it wrong more times then not and you end up with code that is more confusing but not noticeably faster. This is best stated by the following oft quoted saying: "Premature optimization is the root of all evil" Steve
-
I need a few c++ code optimizing tips. Anybody knows where I can find good ones? regards hint_54
Joseph Newcomer's take on optimization[^] Also, Herb Sutter's "101 Coding Standards" has a few good tips on when/where you should and when/where you shouldn't. (I have issues with the book as I only found I can live with roughly 1/4 of the suggestions in the book but that's about 25 more good coding techniques nonetheless.) Meyer's "More Effective C++" has a small bit to say indirectly about optimization in terms of understanding polymorphic behavior and late binding and what it means in terms of the overhead added. However, I think your gonna find more people are focused on readability and correctness nowadays for most programs, unless your the person writing the next GDI+ (please make it faster if you are;P). Threads will continue to be the best place to achieve "apparent" improvements for the end user while allowing you to retain the readability and correctness everybody's preaching.
-
Joseph Newcomer's take on optimization[^] Also, Herb Sutter's "101 Coding Standards" has a few good tips on when/where you should and when/where you shouldn't. (I have issues with the book as I only found I can live with roughly 1/4 of the suggestions in the book but that's about 25 more good coding techniques nonetheless.) Meyer's "More Effective C++" has a small bit to say indirectly about optimization in terms of understanding polymorphic behavior and late binding and what it means in terms of the overhead added. However, I think your gonna find more people are focused on readability and correctness nowadays for most programs, unless your the person writing the next GDI+ (please make it faster if you are;P). Threads will continue to be the best place to achieve "apparent" improvements for the end user while allowing you to retain the readability and correctness everybody's preaching.
bob16972 wrote:
unless your the person writing the next GDI+ (please make it faster if you are).
lol. No, that's not it. It's a lot more simple. I'm running for a coding contest and programs have to be very optimized (if they aren't you might get a "Time Limit Exceeded" error). Besides, I think I should learn this things too. regards hint_54
-
I need a few c++ code optimizing tips. Anybody knows where I can find good ones? regards hint_54
hint_54 wrote:
I need a few c++ code optimizing tips. Anybody knows where I can find good ones?
As already mentioned, measure first. Always keep in mind the 80/20 rule (depending on who is talking this might even be referred to as a 90/10 rule -- I prefer 80/20 because that usually assumes you have not optimized yet, ;) ): 80% of the time is spent in 20% of the code, when you have optimized you might actually reach the 90/10. Optimize the code that is A) called the most often B) more time is spent in the code. These could be two different areas, "A" could be a short module that even saving 2% of the overhead within will make a difference because of how often it is called. "B" could be a long routine that could be redesigned to spend less time within. Reduce redundancy. If you call cos(angle) 10 times for the same angle, consider making a local variable to hold the result and reuse the result 10 times rather than calculate the cosine of the angle 10 different times for the same angle. That may sound obvious, but you would be surprised at how many people don't think about it. Also don't replace a single point of reduncany without a check, usually it is still faster to allocate the local variable and store the result, but for some CPU math instructions it is easier to calculate twice than to allocate the memory use it and deallocate at the end. That is why measuring is extremely important. You will discover faster ways yourself, especially in algorithms, because you will get to know your own code better. _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
bob16972 wrote:
unless your the person writing the next GDI+ (please make it faster if you are).
lol. No, that's not it. It's a lot more simple. I'm running for a coding contest and programs have to be very optimized (if they aren't you might get a "Time Limit Exceeded" error). Besides, I think I should learn this things too. regards hint_54
I was flipping through Meyer's "Effective C++" this morning trying to remember how to do something and I noticed he's not directly concerned with "efficiency" (per se) but he does get to the heart of portable C++ and mentions "efficiency" quite a bit as a secondary argument for many program design recommendations. I remembered your post and thought I'd add this comment in hindsight. Some tips will yield you more efficient code directly and some will point out where designing for robustness, clarity, and caution will yield more maintainable code at the cost of efficiency but these same tips can be reversed to point you to places where you could squeeze out some more speed. The book is a keeper in so many ways it isn't funny so if you don't already have it. Get it. It's also listed here at CP as a recommended book by the masses (or at least whoever put that list together) Take care and good luck in your competition.