|
|
|
|
Back to newsletter 185 contents
"Better, faster, cheaper - pick two, because you can't have all three". This is an old saying which is almost always true. In performance tuning, it turns into "Smaller, faster, higher throughput - pick two, because you can't have all three". Again it's almost always true.
There are a couple of situations when you can improve all three. The most obvious is when you're just clearly doing it wrong, like using the wrong data structure: eg if you're storing ints into a HashMap, they're being converted to and from Integers (either explicitly or through autoboxing). Changing the code to use the appropriate trove map (TObjectIntHashMap, TIntObjectHashMap or TIntIntHashMap) gives you a smaller, faster, and higher throughput implementation, at almost no effort. The fabled super low-hanging fruit!
The other situation is where you find that most of the time things are done one way, and you can optimise for that common case making almost everything better (typically leaving a fallback path for the "old" way for those rare cases when that is still better). The HotSpot compiler does this with speculatively choosing a branch for the JIT compiled code based on the current runtime, with a de-optimisation fallback exception path (where it has to recompile the code). Garbage analysts noticed that most objects die young and so split the garbage collector into a young generation collector which is faster but not as thorough, and old generation collector which is slow but thorough. These situations result in smaller, faster, and higher throughput, but it takes a huge amount of effort to get there.
For JDK 9, Oracle has targeted improving String in this way. Analysis of String indicates that most Strings are ascii, so Oracle have changed String to use a byte array instead of a char array. To make this work efficiently without impacting String performance across all it's uses, took 5 man years to achieve. In the news items, you can find Aleksey Shipilėv's fascinating talk about exactly why it took so much effort.
Now on to our usual links to tools, articles, news, talks and as ever, all the extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 185 contents
