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 that there are many misconceptions running rife and reasons are not understood, but merely followed with blind faith.

One such anti-pattern I have come across is the need to mark as many classes as possible as sealed internal...

*RE-Edit: I see marking everything as sealed internal (in C#) as a premature optimisation.*

I am wondering what are some of the other performance anti-patterns people may be aware of or come across?

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

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