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

Lack of clear program structure is the biggest code-sin of them all. Convoluted logic that is believed to be fast almost never is.

Answer 2

Premature performance optimizations comes to mind. I tend to avoid performance optimizations at all costs and when I decide I do need them I pass the issue around to my collegues several rounds trying to make sure we put the obfu... eh optimization in the right place.

Answer 3

Using design patterns just to have them used.

Answer 4

The elephant in the room: Focusing on implementation-level micro-optimization instead of on better algorithms.

Answer 5

Changing more than one variable at a time. This drives me absolutely bonkers! How can you determine the impact of a change on a system when more than one thing's been changed?

Related to this, making changes that are not warranted by observations. Why add faster/more CPUs if the process isn't CPU bound?

Answer 6

General solutions.

Just because a given pattern/technology performs better in one circumstance does not mean it does in another.

StringBuilder overuse in .Net is a frequent example of this one.