While a cardinal rule of software development is to avoid premature performance optimization, developers still must contend with project deadlines and release dates. As a result, there is often little or no time to work on performance improvements before a release.
"At this point in a project, we have often joked about getting out the 'perf spray,' hoping we could quickly spray on some performance as if it were some sort of flashy paint," says Bart Smaalders, a long-time Sun engineer, in a recent ACM Queue article.
While solving performance problems in the Solaris kernel, X Windows, CDE, and other mission-critical systems, Smaalders noted that most "performance pathologies" centered around a handful of themes, or patterns, that developers repeated time and again. In this article, Smaalders outlines some of these performance anti-patterns, such as:
Fixing performance at the end of the project
Measuring and comparing the wrong things
Algorithmic antipathy
Reusing software (especially, old software)
Iterating too much
Focusing on what you can see, rather what the real problem is
Layering too much software on each other
Using too many threads
And of course, the perennial favorite:
Premature optimization
He also mentions performance anti-patterns that relate to incorrect use of some hardware, such as caches in processors, which is probably a lesson for other caching environments as well.
- Overuse of IO operations or ignoring there are been used - Not having an execution-flow view at all, only component view if any - Incorrect use of exceptions - XML overuse - Incorrect and poor understanding of sw/hw configuration parameters
* Brain dead string handling * A subset of too much XML, an over reliance on the DOM * Frequent use of new/malloc/CreateObject/whatever your memory allocation call or keyword is * I have to mention fixing performance at the end of the project again. I've been hit by that so many times its painful. Yet nobody seems to want to do anything about it. Grrrr.....
I would add just one more: Not finding the right balance between database processing and high level language processing. Some like to do everything in RDBMS, even try to fit tree or graph algorithm in stored procedure; Some people are at the other extreme, they even do the equivalent of table joins in memory.
At our company there are rather catastrophic performance patterns, which we cannot influence at all, as it springs of incompetent management:
* Long incremental, management-driven development - developing a system which turns into something completely different than what was specified in the first specification. * Letting novice, uneducated, uncommunicative or submisive programmers hack the system base. Stupid managers do like submisive programmers very much. * Developing DB system on significantly bad data sample.
I don't know whether there are better conditions & more competent managers in other countries, but here in Czech republic there are manager-posts still reserved for friends & anal-climbers -- the personalistics is nonexistent here. One example: one Prague company I know hired a programmer -- and after 1 year they found out that he does not know how to programm, and that he was just an accountant in IT company.
Previous Topic
