Performance anti patterns

Question

I am currently working for a client who are petrified of changing lousy un-testable and un-maintainable code because of \"performance reasons\". It is clear t

Answer 1

The biggest performance anti-pattern I have come across is:

• Not measuring performance before and after the changes.

Collecting performance data will show if a certain technique was successful or not. Not doing so will result in pretty useless activities, because someone has the "feeling" of increased performance when nothing at all has changed.

Answer 2

I believe it is a common myth that super lean code "close to the metal" is more performant than an elegant domain model.

This was apparently de-bunked by the creator/lead developer of DirectX, who re-wrote the c++ version in C# with massive improvements. [source required]

Answer 3

Michael A Jackson gives two rules for optimizing performance:

1. Don't do it.
2. (experts only) Don't do it yet.

If people are worried about performance, tell 'em to make it real - what is good performance and how do you test for it? Then if your code doesn't perform up to their standards, at least it's something the code writer and the application user agree on.

If people are worried about non-performance costs of rewriting ossified code (for example, the time sink) then present your estimates and demonstrate that it can be done in the schedule. Assuming it can.

Answer 4

Some developers believe a fast-but-incorrect solution is sometimes preferable to a slow-but-correct one. So they will ignore various boundary conditions or situations that "will never happen" or "won't matter" in production.

This is never a good idea. Solutions always need to be "correct".

You may need to adjust your definition of "correct" depending upon the situation. What is important is that you know/define exactly what you want the result to be for any condition, and that the code gives those results.

Answer 5

1. Using #defines instead of functions to avoid the penalty of a function call. I've seen code where expansions of defines turned out to generate huge and really slow code. Of course it was impossible to debug as well. Inline functions is the way to do this, but they should be used with care as well.

2. I've seen code where independent tests has been converted into bits in a word that can be used in a switch statement. Switch can be really fast, but when people turn a series of independent tests into a bitmask and starts writing some 256 optimized special cases they'd better have a very good benchmark proving that this gives a performance gain. It's really a pain from maintenance point of view and treating the different tests independently makes the code much smaller which is also important for performance.

Answer 6

Once I had a former client call me asking for any advice I had on speeding up their apps.

He seemed to expect me to say things like "check X, then check Y, then check Z", in other words, to provide expert guesses.

I replied that you have to diagnose the problem. My guesses might be wrong less often than someone else's, but they would still be wrong, and therefore disappointing.

I don't think he understood.