Optimizing Code [closed]

Answer 1

Be sure to have enough unit test to make sure any optimization you will make will not break anything

Make sure to qualify your execution environment. Sometime, a simple change in the execution options can go a long way.

Then and only then, start analyzing the code.

The rewrite decision (for an already working code) should only be considered if there is enough future evolutions which may not be supported by the current architecture.
If simple fixes can speed up a code which is not supposed to evolve much, no complete rewrite should be necessary.

The criteria to stop is usually determined in collaboration with the end user (the client), but I would suggest a formal document fixing the goals to achieve with this optimization process.

Answer 2

First decide what your optimisation goal is - set a target for timing of particular operations on a given hardware platform. Measure the performance accurately (ensure your results are repeatable) and in a production-like environment (no VMs etc unless that's what you use in production!).

Then if you decide it's already fast enough, you can stop there.

If it's still not good enough, then some extra work will be needed - which is where profiling comes in. You may not be able to use a profiler very well (for example, if it impacts the behaviour too much), in which case instrumentation should be used instead.

Answer 3

The language I have done most optimisation in for numerical computation in C and C++ on Linux. I found that profiling, while useful, can skew your run time results so that cheap, frequently called operations (like c++ iterator increments). So take those with a grain of salt. In terms of actual strategies that produced a good speed up are:

1. Use numerical arrays rather than arrays of objects. For example, c++ has a "Complex" datatype. Operations on an array of these were a lot slower than a similar operation on two arrays of floats. This can be generalised to "use the machine types" for any performance critical code.
2. Write the code to allow the compiler to be more effective in its optimisations. For example, if you have a fixed size array, use array indices so that auto vectorisation (a feature of Intel's compiler) can work.
3. SIMD instructions can provide a good speedup if your problem fits into the kind of domain that they are designed for (multiplying/dividing floats or ints all at the same time). This is stuff like MMX, SSE, SSE2 etc.
4. Using lookup tables with interpolation for expensive functions where exact values are not important. This is not always good, as looking up the data in memory might be expensive in its own right.

I hope that gives you some inspiration!

Answer 4

Assuming the code needs optimization, then i would use : 1.) Optimize the way buffers are handled used - Cache optimization. Cache latencies are one big area which suck CPU cycles like bad. roughly in range of 5-10 % overhead So make use of data buffers in cache efficient manner.

2.) Critical loops and MCPS intensive functions can be coded in assembly language or using the low level intrinsics provided by the compiler for that h/w target.

3.) Read /writes from external memory are cycle expensive. minimize external memory access as much as possible. Or if u have to access do it in a efficient way(PReloading data, PArallel DMA access etc..)

Generally if u get around 20% optimization(best case) by following optimization techniques, I would say thats good enough and best enough without any major code restructure, algorithm redesign. After which it becomes trick, complicated, and tedious.

-AD

Answer 5

Profile before attempting any optimisation.

9 times out of 10, the time won't be consumed where you might guess it is.

The usual unsuccessful strategy is micro-optimisation, when what is actually required is the appropriate algorithm.

Obligatory Donald Knuth quote:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"

Answer 6

All good answers.

I would refine the "measure" part of the advice. I perform measurement for the purpose of quantifying any improvements I might make. However, for finding what needs to be fixed (and that is a different purpose), I get several samples of the call stack, manually.

Suppose, for simplicity, the program takes 20 giga-cycles to run, when it should take 10. If I pause it 10 times at random, then in 5 of those occasions, more or less, it will be in one of those unnecessary cycles. I can see if the cycle is necessary by looking at each layer of the call stack. If any call instruction at any level of the stack could be eliminated, then the cycle is unnecessary. If such an instruction appears on multiple stacks, eliminating it will speed up the program, by an amount which is approximately the percentage of stack samples it is on.

Any instruction that shows up on multiple stacks is suspect - the more stacks, the more suspect. Now, call _main is probably not one I can remove, but
foo.cpp:96 call std::vector::iterator:++
if it shows up on multiple stacks, is definitely a focus of attention.

One may, for style reasons, not want to replace it, but one will know roughly what price in performance is being paid for that choice.

So optimizing consists of identifying suspects and finding a way to replace or eliminate them.

The hard part (and I've done this many times) is understanding what is necessary and what is not. For that, you're going to absorb an understanding of how and why things are done in that program, so if some activity is a cycle-hog, you can know how to safely replace it.

Some cycle-hogs may be simple to fix, but you will quickly run up against ones that you don't know how to safely replace. For that, you need to be more familiar with the code.

It will help if you can pick the brain of someone who's already worked on the program.

Otherwise (assuming the code is ~ 10^6 lines, like I've worked on) you can get some speedup fairly easily, but to go beyond that, it can take months to get to where you're comfortable making significant changes.