JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 047 contents | All Javva's articles

Diary of a Hutt

September 8. Project Xenon needs tuning. Well, we have actually been maintaining performance targets, service level agreements and running performance tests on the project since its inception, a year and a half ago. But that was basic stuff, because they never had a system which included anything other than minimal skeleton functionality - until now. Not that I'm surprised, I've yet to see a complex system that didn't need performance tuning at some point, and we are detecting the issues early in the schedule thanks to my proactive approach.

September 15. Preliminary tests indicate we have sixteen primary performance targets, distributed amongst CPU, memory, disk I/O, network I/O, database I/O, GC. And two orders of magnitude performance to improve in some cases. We have already had a few meetings to prioritize the targets. Though past experience suggests that the order doesn't really matter since the performance bottlenecks will change both as we tune the system and as the system has functionality added to it. But after all, if we didn't set these kinds of targets, we wouldn't have anything to argue about - whoops, I mean discuss - when we meet for progress reports.

September 22. I've maneuvered Weevil into becoming the QA liaison for Xenon performance, starting beginning of January. I've maintained that my schedule requires an extra QA resource for Xenon performance management, and basically arranged for Weevil to be the one, and when to start. Looks to him like it's a step up, because he will be doing essentially what I should be doing, management-wise. But he doesn't know the profile of this type of work. My estimation is that Q4 will see some huge strides in performance, as we find what I call the "stupidity" bottlenecks. These are just where someone has done something stupid in code, causing an order of magnitude slowdown in performance. I see those all the time early on in development. Then, just as he takes over, we should eliminate the last of these, and get bogged down into the phase of tuning which I call "see-saw". This is the stage where functionality is still being added, changed and bug fixed at a rapid enough rate that you cannot make any performance tuning progress at all, because the "stupidity" bottlenecks are gone. In this phase, any tune that you make will be either in the wrong part of the system, or will get overridden by some functional change or bug fix, or will get cancelled out by some change elsewhere. Ever heard the phrase "poisoned chalice". Heh heh, he will never even begin to understand why it was that after he took over, the performance improvement process fell off a cliff.

Javva The Hutt.

Back to newsletter 047 contents