Optimizing Code [closed]

Answer 1

Don't even bother to try anything without some sort of profiling, I can't stress this enough! Unfortunately, all the profilers I know either suck or are expensive (Yay for business costs!) so I'll let others make recommendations there :).

You know you need a re-write when your data tells you that you need a re-write, which sounds recursive, but really just means the the cost of your current architecture or software stack is enough by itself to push you over the performance cliff, so nothing you do in local changes can fix the overall problem. However, before you get out the File->New... command, make a plan, build a prototype and test the prototype does better than the current system for the same task: it's amazing how often there is no noticable difference!

Answer 2

First of all do not forget these :

• Premature optimisation is root of all evils
• Performance come from the design

Secondly;

Don't assume try and see

I think this is the cardinal rule of optimisation, test it, unless you test it and prove that it's working you wouldn't know.

In your case what I'd do is, firstly refactor the code, have grasp of it.

If you got unit tests you are lucky just go function by function and specifically go and check most frequently called code (use profiling to observe calls and where are the bottlenecks). If you don't have tests, write some basic tests which confirms the overall output in some conditions so you can ensure that you are not breaking anything and free to experiment.

Answer 3

As many others have already stated, profiling is your first step.

I would add that focusing on data structures and algorithms as a first step is generally more profitable than diving straight into micro-optimizations.

For one thing, the compiler will normally perform a lot of the classic optimization tricks for you anyway (and often better than you). This is especially true in more modern languages such as C# than it is in older, less constrained, languages C as the compiler has more knowledge of program structure; worse still, confusing your code by "optimizing" it can actually make it harder for the compiler to apply its own, more efficient, optimizations.

Mostly though, there is just a lot more scope to improve things when you start improving the big-oh of your operations. For example, searching a linked list is O(n); meaning the time taken to search it increases at the same rate as the size of the data stored in it. Searching a hashtable is only O(1), so you can add more data without increasing the time to search it (there are other factors when we leave the theoretical world so this isn't quite true, but it is true enough most of the time).

Messing with your loops so they run from high to low so the generated code can save a couple of clock cycles with a JumpIfZero rather than a JumpIfLessThan is probably not going to have quite the same degree of impact!

Answer 4

Steps:

1. Measure
2. Analyze
3. Decide
4. Implement
5. Repeat

First get a profiler to measure the code. Do not fall into the trap of assuming you know where bottlenecks are. Even afterwards, if your assumptions prove to be correct, do not think that you can skip the measurement step the next time you have a similar task.

Then analyze your findings. Look at the code, identify the bottlenecks you can do something about that will have an effect. Try to estimate how much of an improvement this will be.

Decide if you want to go down this path, based on your analysis. Will the gains be worth it? Is a rewrite warranted? Perhaps you find that though it runs slow, it's as good as it is going to get or that you're close to the top of the performance curve where the work needed to eek out a miniscule improvement isn't warranted.

Implement your changes, do the rewrite if necessary, or refactor the code if that's the path you've gone down. Do it in small steps so that it becomes easy to measure if your change gave what you wanted or if you need to backtrack a step and try a different route.

Then go back to the start and measure, analyze, decide, implement, etc.

Also, on the note of refactoring code. The first things you should change are the big algorithm-level approaches. Things like replacing a sort algorithm with another that performs better, etc. Do not start with line-level optimizations, like how to get a line that increments a value to go slightly faster. Those are last level optimizations and usually not worth it, unless you're running in extreme performance conditions.

Answer 5

Besides profiling, as everyone mentions, the two solutions I always head for first (after profilling) are Memoization and Lazy loading, they are both easy to implement and normally make a big difference.

Answer 6

Good strategies

Besides the mentioned basic laws of optimization (measure, don't optimize if not necessary), and although the question explicitly asked for efficiency, I always refactor such code during my inspection.

Typically code with bad performance is also badly documented. So with the refactoring I make sure the code is better documented by itself and easier to understand. That's the base for being sure I know what I'm optimizing (as in most cases the requirements for that piece of code will also not be completely available).

When to stop

With a really bad performing application, you will typically have a spike in the runtime shown for a single method (or set of related methods) in your profiler, showing a programming bug or design flaw. So I typically stop if the runtime of profiled methods is distributed mostly equally (or if the majority of bottleneck methods shown is platform code, like Sun Java methods). If further optimization is demanded by your customers you will have to redesign larger parts of the application instead of optimizing existing code.