Avoid the Dreaded Rewrite With IBM Rational Developer for Power Performance Advisor
Performance testing is an important aspect of software development. Those who disagree should query their customers, who most likely face a barrage of progress bars and hourglasses. Although performance engineering is important, it’s difficult to find time to squeeze it into an already packed schedule. Most developers are so overwhelmed with functional requirements, defects, meetings and deadlines that analyzing an application’s performance doesn’t even make the extended to-do list. In reality, performance is checked at the end of the release and is usually represented by a checkbox on a document to be skimmed by upper management.
When a performance problem does occur, alarm bells go off, high-ranking executives start asking questions and considerable effort is required by the team to fix the program’s fundamental flaw. Make no mistake; the effort at this point is usually monumental. That performance problem—most likely introduced during the design stage of the release—lurked in the shadows during the development phase, going unnoticed with simple test input, only to rear its ugly head when fully exercised during the production testing near the end of the release cycle. Developers suggest strategies peppered with such frightening words as refactor, rework and even the dreaded rewrite. But with a little luck and many sleepless nights and stressful meetings, that all-important checkbox finally gets checked.
Regardless of how busy, overconfident or lazy we may be, if the effort of performance engineering is low and the benefit is potentially high, most of us will do it.
Afterward, it’s likely all parties involved will commit to greater diligence and put forth grand plans for a utopian development environment. However, as development commences and deadlines start appearing—which are then joined by defects, requirement changes and other commitments—those grand plans are forgotten, and phrases like, “We’ll tune the performance after we get it working” are once again heard through cubicle walls.
How does a profession of analytical, intelligent people continue to fall repeatedly into the same trap? Are we apathetic? Are we so overconfident in our skills that each time around we assume we couldn’t possibly make the same mistakes? Or are we just spread too thin and performance engineering falls off the radar? Whatever the reason, I put forth a simple solution: Make performance engineering easy. Regardless of how busy, overconfident or lazy we may be, if the effort of performance engineering is low and the benefit is potentially high, most of us will do it.
Rational Performance Advisor
The experienced performance engineer probably is conjuring images of tprof printouts, oprofile line data files, stack traces and compiler manuals right now. As I said, performance engineering is difficult. For those developing on IBM Power Systems* servers running AIX* or PowerLinux*, help has arrived. This June marked the release of Rational* Developer for Power Systems Software* 8.5, including the first release of the Rational Performance Advisor component. It is specifically designed to open the world of performance engineering to the application developer, without the complications associated with traditional low-level performance-analysis tools. By combining performance engineering with a rich desktop integrated development environment (IDE) such as Rational Developer for Power*, performance analysis is no longer a distinct stage of development; now it’s a part of making a change or delivering a feature.
Picture a scenario where a developer is checking in code and he or she wants to know how it affects performance. Typically, for such a daunting task, most developers just click “Deliver” and mutter a short prayer. With Rational Developer for Power, the developer can press one button and be instantly transported from the traditional Eclipse-based IDE to—drumroll, please—a familiar Eclipse-based performance analysis tool. Now, all the developer must do is tell Rational Developer for Power how to run the application, which typically takes less than a minute. If the feature-rich debugger on Rational Developer for Power has already been used to debug the application, that step is taken care of.
This is the point where the magic happens. When the user clicks “Launch Program and Collect Data,” Rational Performance Advisor contacts the server, launches the program, launches data-gathering tools such as tprof or oprofile to collect information about the program, analyzes binaries, and then works to present all of that information in several intuitive views. This magic still applies even if the program was already running; you need only to point Rational Developer for Power at the right application and click.
What if this short process is just too much work for you? Let’s say you need to do a performance run on your application after each nightly build and 60 seconds per night can make or break you. Rational Performance Advisor takes this into account and provides a mechanism to establish daily and weekly performance analysis runs of a program. All of the results are saved, tagged and presented in a familiar explorer view.
Knowledge Is Power
Now that the development team is actively monitoring the performance of the application, an obvious question arises: What if this diligence pays off? What if, after the latest performance analysis run, the developer clicks “Compare to Baseline” and discovers problems? Thankfully, just by opening the comparison view, the developer is already on the path to discovering the cause of the slowdown. The comparison view displays how the performance of each function has changed between two runs, making it readily apparent which functions slowed down.
From here, the developer can either look at the source code, annotated with timing information, or examine call information through the invocations view. The source browser combines source code, timing information and inlining information into a single, integrated view—something that would be beyond the ability of most developers. Developers can easily zero in on their changes or the hot areas of code and see how performance has changed. If the performance degradation is complicated and their changes caused something downstream to slow, the invocations view can indicate how the function-calling pattern of the application has changed through an intuitive graphical view. Again, this feature is probably beyond the ability of most developers, but it’s instrumental in finding the root cause of certain types of performance issues.
Finally, what if it’s still not clear what went wrong? Or what if a developer wants to improve performance but isn’t sure where to start? Rational Performance Advisor does exactly what the name implies—it advises. Not only can the program display performance information for the user, it also can analyze information and provide recommendations on how to improve performance. It examines the server settings, compiler and compilation options, inlining, etc. This information is run through the logic inference engine with the goal of improving the application’s performance.
Performance Engineering Made Easier
Performance engineering is a critical challenge for development teams, and it's only becoming more difficult as more complicated applications and hardware are developed. Rational Performance Advisor was designed to make performance engineering easier. Its simple and efficient approach to performance runs allows developers to monitor performance throughout the development lifecycle and avoid potential 11th-hour disasters.