the corner office

There's an interesting article on Artima called How To Go Slow, listing a number of performance crimes (mainly geared towards C++ apps). The first section is on complexity, with a pretty graph of asymptotic orders. Somewhat apropos given that I just wrote an exam on the subject this morning. Yes, using bubblesort is a programming crime of the worst order, and quicksort is faster on average, but I couldn't help thinking 'ah, but you could avoid the degenerate quadratic behaviour of quicksort in the ironic case where the collection is already sorted by considering a merge sort (if you could handle the linear additional space requirements), or an accelerated heapsort, both of which provide n log n performance in both average and worst cases...' I'll be over this affliction by Monday, I promise.

Some of the issues, while valid, are less relevant for your average Java/J2EE developer. You generally don't need to know or care how your data is being sorted, just let the API do it for you. (*)

In Java/J2EE apps, ignoring the cost of many slow, bloated frameworks and libraries you've perhaps chosen or been forced to use, you can probably get away with looking at 4 things to boost performance, (and in this order of severity):

1. hitting DB, network, or file system more than you need to
2. hitting contended synchronized code more than you need to
3. doing string manipulation more than you need to
4. hitting maps and complex data structures more than you need to (especially when combined with #2)

Am I missing anything?

Nothing is ever a replacement for actually having cold, hard profiler and load data to pin-point performance problems, but if you're looking to speed your app up, you can't go far wrong if you start looking at 1-4 above. The biggest performance bottleneck of most server-side apps isn't a lack of l33t performance coding and optimising, it's just doing work you don't need to.

Of course, I'm copping out a bit. The definition of 'need to' varies from programmer to programmer. Some programmers will jump through all sorts of hoops and complicate things in the interests of performance, others will do all sorts of inefficient things to keep their code abstracted and/or clean. Excluding obviously redundant processing, somewhere in the middle is a balance, and therein lies the skill and art, &c &c.

(*) according to the Javadocs, it's a modified mergesort for Lists and a modified quicksort for arrays... I had to look.