I was just reading an article entitled "Optimization of Computer Programs in C" and it got me to thinking about what I do to optimize my code.

The answer, sadly, is probably not enough. I use the optimization flags for speed in gcc, but that's about it.

So I wondered what other people did to optimize their code. I'd like to hear what methods work and what doesn't.

Optimisation is never on my mind when I am starting out with new code. Initial focus should be on making the code work. Then If there are any performance issues, profile the code and find the bottlenecks. Optimisation flags help only if you know what they do. In gcc, O2 can give you better performance than 03(highest optimization level) in many cases. So, just blindly applying flags doesn't help always. Bottlenecks can further be removed by using inline assembly or the the tricks specified in the link you gave. But compilers nowadays are more smarter than humans to figure out where to use such tricks.

This post has been edited by Xing: 19 Jul, 2007 - 10:52 PM

I've found over the last number of years that the importance placed on optimization has decreased from what it was when I first began in the industry, and for good reason. While optimization is usually very important in real time systems, the vastly increased processing power over the years has often made up for common inefficiencies in code. Also, as Xing mentioned, the newer compilers are designed with a certain amount of optimization in mind, as the common inefficiencies are well known.

I still use the common methods of optimization once i have a working piece of code, but I'm not sure what level of value t brings anymore - more habit that anything else.

This is due to the vast amounts of progress in Computer Hardware. In the beginning RAM was extremely limited, so it was worth the time to free up 128k. Now, with gigs & gigs of available RAM, vastly increased Level 2 cache, & processessing speeds above 3 ghz, it isn't worth company time/per hour to pay a coder to save 128k of RAM usage, or an extra loop. Heck, there is more computing power in my video card than I had in my 1st PC!

I think it's good thing to get adopt certain standard coding habits. Fair enough that hardware compensates for a certain amount - but when you have to rewrite chunks of sloppily written code because the project has become unwieldy isn't a good situation to be in either.




That's good to know, as some of the optimization tricks can appear quite unusual, and aren't exactly beneficial to code readability either.

Use good algorithms, don't sort in O(n^2) when you can do in with O(n*lg(n))

Any amount of optimizations on a O(n^2) algo will soon be outweighed by the order of magnitude difference against a O(n*lg(n)).

In recent years I have found a great irritation in what some people say about optimization. Basically people generally want to ignore it. However, the world of computing has not gotten to the point (and I don't believe that it ever will) that optimization is not needed. It is true that the compiler can find ways to tweak your loops and stream your code though the processor, but it can't choose a better algorithm for you.

There are basically two types of optimization in my eyes: Clock ticks and program logic.

In the "clock ticks" mode you are optimizing a given algorithm on a given platform. It is important to note that by platform I mean: processor/operating system/compiler. In this mode you are stepping though machine code looking at loops/branches etc. The idea is to optimize your code so that your compiler will generate the fastest possible code. You must understand that just because you have it tricked-out as fast as it can go, means nothing if there is a change to the platform (even a newer version of the same compiler).

Lets face it, there is little need for this kind of optimization in most real world applications. Maybe game designers drool over the idea of getting a few more FPS's but the managers are more interested on it operating smoothly on many platforms than being tricked out on 1.

The other mode of optimization deal with smart programming. Choosing the right algorithm. Understanding technologies such as caching and using them effectively. (I just wrote a db application that bypassed the cache and was fantastically improved when a more senior programmer pointed out that I was bypassing the caching mechanism). -- Oddly enough I think that this is more difficult area to become proficient in. With modern technologies often overlapping it is difficult to keep up and know what the best practices are.

I have seen many a guru point out an "optimization" just to be shown a better way -- heck it has happened to me over and over.

I think this is why the focus has fallen away form optimization. You can spend a lot of time developing what you think are great practices, just to learn that they are now out-of-date. -- but I still say that you should try to program smarter and not harder!

I agree with this. I try to use the "correct" algorithm in a given situation. Never thought of that as optimization, though. I'm starting to take a look now at what works best in given situations: Allocating memory from the stack or the heap. This has been done to death, so it's easy to research, and it seems a good start in my quest to get better at optimization.

If you're planning on writing a portable application, its best to let the compiler do all the optimization.
If you add inline assembly code, your code may not work on other systems.