Performance management-are you planning?

Original article:
Http://www-128.ibm.com/developerworks/cn/java/j-jtp03253/

Knowing when to optimize is more important than knowing how to optimize

Brian Goetz
Chief Consultant, Quiotix Corp
June 21, 2003

Where does the performance problem come from? Programming options that cause performance problems include many types-inefficient algorithms, redundant computing, poor resource allocation and usage, excessive synchronization, or obviously low-efficiency design. But more common and destructive errors are management and method errors, rather than programming errors. In this part of Java theory and practice, Brian Goetz will discuss some of the most common performance errors encountered when using the Java language in the project. Share your thoughts on this article with the author and other readers in the attached forum. (You can also visit this forum by clicking the discussion at the top or bottom of this article .)
Performance management is generally regarded as a kind of magic, because performance problems usually occur after the application is developed. At that time, it was hard to determine their root causes. However, once the cause of the performance problem is determined very accurately, it is often relatively simple to correct it. Engineers are usually quite creative in finding more effective ways to execute special tasks (sometimes they are too creative ). For any given performance problem, you can use the cache to reduce redundant computing or simply add more hardware. The solution may be as simple as replacing it with a more effective algorithm. However, it is difficult to clearly identify the root cause of performance problems, and it is even more difficult to design complex programs. Therefore, we must first make them free of performance problems.

Although programming decisions, such as sub-optimal selection of algorithms or data representation, cannot reuse the results of previous calculations, or poor resource management-it is often considered a direct cause of performance problems, but there is a deeper cause for most performance problems: performance management, goals, and measurements cannot be integrated into the development process first.

Question? What's the problem?
How do you know when there will be performance problems? For most development teams, the answer (in the words Potter Stewart, judge of the U.S. High Court of Justice, describes the crime) is: it is only known at the time of the incident. This is the core of the problem-performance goals, measurements, and measurements are often not taken into account until it is found too late.

The most common performance management policy is ...... It usually takes one of the following two forms:

Ignore performance before application development is complete
Optimization during development, which usually means to focus only on minor performance considerations, while ignoring large aspects
These two policies share the same basic problem-they do not regard performance management as an integration part of the development process.

Defective Performance Policy A: Ignore performance completely
The first method is to completely ignore performance. This method regards performance as something that can be handled at the end of a project, such as writing release instructions or building an installer. This strategy basically depends on luck, because the computer computing speed is faster than a year, so it can always cope with performance.

This kind of luck-based problem (even when there is a high probability of success) is the framework where you don't handle it, identify its root cause, or specifically solve it in case of a performance problem. You have not scheduled time for performance measurement and tuning in the development plan. This is a bit like a website. Apart from installing a firewall with the default configuration, we did not try to use a consistent security policy and discovered that they have been stolen. Where do you start?

Defective Performance Policy B: optimized during development
Another common but even worse way is to make minimal performance considerations drive architecture and design decisions. The reason why developers like code optimization is that it is satisfying and fun. However, it is more important to know when to optimize the concerned code and when to solve performance problems during the development cycle. Unfortunately, developers generally cannot intuitively determine where the performance problem will actually occur in the application. As a result, they waste a lot of effort to optimize the code paths that are rarely executed, or worse, they damage good design and development practices to optimize components that didn't have any performance problems earlier. When you write your code, you can easily see the tree instead of the tree in terms of performance.

Running code paths as quickly as possible does not guarantee that the final product will be executed well. Local Optimization cannot make up for the design with low efficiency, even if every component is implemented as fast as possible. Optimization policies during development use low-level performance considerations to replace performance policies for the entire project, and you cannot be sure that you actually have a performance policy.

One of the many problems with optimization during development is that it ignores the inherent risks in optimization. A few optimizations will also make the design better and have fewer errors, but these are exceptions. Optimization typically balances performance with other considerations (such as clean design, clarity, flexibility, and functionality. Optimization costs and risks: it may introduce errors, restrict code functionality, or make it more difficult to use or maintain. Make sure it is worthwhile to do so before you can afford these costs.

Use performance management as part of the development process
From the very beginning, performance measurement and planning should be integrated into the development process, and separate and staggered iteration of development and performance measurement and optimization. This means setting performance goals, preparing performance measurement solutions, and review code performance frequently during code development. It is best to save the old test results in the database so that you can easily compare the performance changes when you change the code.

Independent iterations of development and performance allow you to concentrate on writing code that works correctly during the Development iteration. If necessary, you will also know that there will be an appropriate opportunity to improve performance soon. If you think of a clever trick to make the code run faster, add a comment in the code to describe your thoughts in detail, but do not implement it now! This is not the time for optimization. If this is ultimately required, you will be back when you are able to commit. Performance Optimization should be driven by performance goals and supported by performance measurements. Other things are just "secondary ".

Measure twice, and then measure several times
Measurement is a key element in performance management. Think about it: Will a given trick make the code run faster? We are going to verify this. Use performance measurement tools to test performance before and after implementation. If no improvement is detected, what should I do? Then, we are ready to take back your plans. If you cannot test the benefits, why do you have to take the risk of damaging the work code?

Measure the performance of an application or its components during a performance iteration and compare them with measurements of previous iterations. Are you slowing down in some ways? Find out the cause. If it fails to reach the performance goal, you do not have to change it, but now you have gained valuable feedback about the impact on performance after your change.

Have you achieved the goal?
If you do not have quantitative performance goals and measurement plans that support them, performance tuning seems meaningless. How do you know that you have achieved the goal? Other development phases (such as coding, testing, and packaging) define goals-implement this set of features and correct these errors. The performance stage should also have structures and objectives.

Performance goals are especially important when you focus on performance from the outside (whether it is the customer or another department in the company. When someone tells you how to make the program run faster, you should first ask "How fast must I make it ?" Otherwise, you may invest too much resources in optimization, but you still cannot satisfy the customer. I spent 12 minutes to improve the program running speed by 30%, but some people did not expect the "oh, I originally hoped that the speed will increase by 50% .", This is disappointing.

Conclusion
Performance management includes not only optimization, but also many other things. It has a framework for deciding when to optimize and when not to optimize. You should make these decisions based on specific performance goals, measurements, and planning, rather than intuition.

References

For more information, see the original article on the developerWorks global site.


Participate in forums related to this article. (You can also visit this forum by clicking the discussion at the top or bottom of this article .)


The book "Java Performance Tuning (OReilly & Associates, 2003)" by Jack Shirazi contains a large number of recommendations on individual optimizations and how to measure Performance and intelligently process Performance Tuning.


Jack Shirazi's Java Performance Tuning website contains links to many Performance-related articles and techniques.


Java Platform Performance: Strategies and Tactics (Addison-Wesley, 2000) co-authored by Steve Wilson and Jeff Kesselman) it includes some in-depth case studies on the actual performance problems encountered during Java class library development.


Another third-party Design for Performance article by Brian Goetz, JavaWorld, provides tips on how Design decisions affect Performance.


The article "Spotlight on Java performance" (developerWorks, December 2001) illustrates a wise and practical performance management policy for IBM Java Virtual Machine projects.


"Optimize your Java applications performance" (developerWorks, June 2002) demonstrates an iterative performance tuning strategy that uses Algorithm Improvement, high-speed cache, and low-level performance tuning.


You can find hundreds of references on Java Technology in the worker worksjava technology area.


About the author
Brian Goetz is a software consultant and has been a professional software developer for the past 15 years. He is the chief consultant of Quiotix, a software development and consulting firm in Los Altos, California. Please refer to Brian's and upcoming articles on popular publications in the industry. You can contact Brian through a brian@quiotix.com.