|
|
|
|
Back to newsletter 169 contents
I increasingly see the draconian statement that "The biggest bottleneck is always the one to fix". Any accompanying justification usually says that because systems are complex, fixing anything else is a probable waste of time because they might disappear whereas the biggest bottleneck will always be there.
I've always taken a more flexible approach, that your experience and knowledge of the application should inform you which bottleneck to target - for exactly the same reason, that since systems are complex, fixing an easier bottleneck might adjust the system so that the biggest bottleneck gets easier or goes away, and this way you get the biggest return for your time.
But is it possible for the biggest bottleneck to go away or reduce without directly targeting it? Actually it's easy to find scenarios where this happens. For example, take a JVM where operation X is the biggest bottleneck taking a very long time. Execution profiling shows some subroutines where X spends a lot of time. A simplistic view might make you target the algorithm X is following. Tuning fails; a more sophisticated or subsequent profiling including memory profiling shows X creates a lot of temporary objects and it's not the algorithm itself that's slow. You might then target reducing the number of objects that X uses. Again the tune fails, because in fact the heap has exceeded the available RAM on the box and is paging, the actual issue is that X cycles through enough new objects each time to cause a GC that requires paging, slowing everything down dramatically. The actual bottleneck for X being slow here is that the heap is sized too large. A holistic view of the system might have made you target the heap size first as it's the easiest to fix in any case, and you would have fixed X at the same time!
Of course proponents of the "fix the biggest bottleneck" will just say that was the biggest bottleneck. But that skirts the issue - you cannot possibly know what the biggest bottleneck is beforehand, you can only determine what it is using your various measuring tools, and these tools can mislead you. Easily mislead you. There are thousands of metrics, hundreds of things that commonly go wrong, dozens of ways to measure or profile a system at many different levels. My advice is don't blindly follow the "fix the biggest bottleneck" maxim, be aware your measuring tools may be telling you one bottleneck is the biggest but they can only tell you what they know about, not absolute reality. Use your knowledge and experience. I find that targeting easier bottlenecks to fix often gives you excellent insight into the system, and is rarely wasted.
Now on to all our usual sections: 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 169 contents
