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 064 contents

http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=366&page=1
Performance Anti-Patterns (Page last updated February 2006, Added 2006-03-29, Author Bart Smaalders, Publisher ACM Queue). Tips:

• Don't wait to the end of the project to fix performance - you are building in disaster.
• Have appropriate performance targets - the system shouldn't degrade, and should be competitive.
• A good benchmark is: Repeatable; Observable; Portable; Easily presented; Realistic; Runnable.
• Avoid selecting benchmarks that don?t really represent your customer.
• Selecting a benchmark is asking for that aspect of performance to be optimized, probably at the expense of other aspects that are not being measured. Be careful what you ask for, because you?re likely to get it.
• All the really big improvements in performance typically come from changes in algorithms.
• A key part of algorithm selection is having a realistic benchmark or workload to evaluate it.
• Document the assumptions about the externalities affecting the code and provide some sort of programmatic means of validating those assumptions later on.
• Track maximum hash chain lengths on an open hash, as well as the total hash table population; this allows for the easy identification of both undersize (or the need for self-resizing) hash tables and poor hash functions.
• Software reuse is a fine goal, but beware of violating the assumptions made during its development.
• If your application is doing unneeded or unappreciated work, then eliminating such waste is a lucrative area for performance work.
• What often matters for applications is the end state of the program, not the exact series of steps used to get there.
• With the exception of correctly used memory prefetch instructions, the only way to go faster in software is to do less.
• Premature optimization can be counter productive.
• What you see easily is not necessarily the problem - look for the real cause rather than the easily found issues.
• Layering incautiously significantly increases the footprint and function call overhead.
• Limit the number of threads to near the number of CPUs and use a work-pile model and asynchronous I/O to multiplex the worker threads against the tasks to be done.
• Optimize for the common case.

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=74
Performance Investigator (Page last updated March 2006, Added 2006-03-29, Author Scott Barber, Publisher Better Software Magazine). Tips:

• Leaving performance testing to the end of development is very risky as failure can require extensive rework.
• Determine early on the capacity of the selected server hardware, the available network bandwidth, response times and throughputs of critical functionality, and configuration errors in load balancers
• Every change to the system can cause unexpected performance changes and thus require the validation process to start over.
• Performance testing is naturally investigative due to the lack of predefined requirements or quantifiable expectations.
• Performance testing often uncovers a single issue that makes additional performance testing wasteful until that issue is resolved. This contrasts with functional testing where it is rare for a single test failure to essentially disable validation testing of the entire system.
• Functional testing is about validation - checking that the software works as per spec. Performance testing is mostly investigation, aiding in understanding how the application works.
• Start performance planning with an expression of intent, e.g. "Web server with static prototype available for X days. Investigate various configurations for response time, throughput, memory allocation, network bandwidth, latency, impact of firewall, proxy server, load balancer configurations. Collect configuration data to aid in future tuning and data to assist in validating adequacy of existing network components".
• The expression of intent for a performance investigation can be accomplished in a single work session involving the lead performance tester, the lead developer, the project manager, and a copy of the project plan to identify key project deliveries.
• Information to include in the performance investigation intent: Investigable deliveries; Duration of each delivery investigation; Key areas of investigation.
• Each performance investigation intent should lead to a one page investigation strategy description including: Intent of the investigation; Prerequisites of strategy execution; Tools and scripts required; External resources required; Risks to accomplishing strategy; Data of special interest; Areas of concern; Pass/Fail criteria; Completion criteria; Planned variants on tests; Load range; Tasks to accomplish strategy.
• Each task in a performance investigation strategy should be detailed in up to one page with task details. e.g. with level of load, resources to be monitored, who and how to set up the monitors, the configurations to be monitored. Information to include: Strategy task execution method; Specifically what data will be collected; Specifically how that data will be collected; Who will assist, how, and when; Additional information needed to repeat the investigation; Sequence of tasks by priority.
• Following a performance investigation execution, you should: Analyze results immediately and re-plan accordingly; Communicate frequently and openly across the team; Record results and significant findings; Record other data needed to repeat the test later; Revisit investigation priorities after two days.

http://today.java.net/pub/a/today/2006/02/23/smooth-moves-solutions.html
Smooth Moves (Page last updated February 2006, Added 2006-03-29, Author Chet Haase, Publisher java.net). Tips:

• Much of the choppiness in animations came from two general sources: Color difference: The amount of color change per pixel needs to be minimized; Vertical retrace: Artifacts coming from computer display technology.
• Make your animations smoother by reducing the amount of color change for each frame of the animation.
• An object that is closer to the background color causes the pixels to shift less as it moves around on that background; the background pixels do not need to shift as much in RGB space to represent the object color, and this difference in color shift results in smoother perceived movement for the object.
• Anti-aliasing softens the edges by fading the object color out translucently on the edges. This has the net effect of a smoother ramp up to the object color and back to the background color as the object moves around over the background.
• Motion Blur: This is the effect of drawing ghost images of the object as it moves around. draw the object in its real location in its true colors, and you draw some number of ghost images where the object used to be in some faded color (translucent, so that the background color shows through these ghost images).
• Hard edge movement trips up your eyes more than irregular edges; tracking artifacts in an irregular shape is more difficult, making artifacts easier to disguise with such shapes.
• Vertical retrace artifacts come from rendering to the screen at the same time as the screen is being refreshed from video memory - the artifacts can show the top half and bottom half of two adjacent frames. Avoid these by: Minimizing color differences; Minimizing linear shapes; Minimizing the distance an object moves between frames.
• Vertical retrace artifacts can be avoided by waiting for the "vertical blank interval," and synchronizing draws with that. Applications that use the FlipBufferStrategy (in fullscreen mode) get this for free.
• [Article describes in detail an sample applet that implements many techniques for smoothing animation artefacts].

http://www.devx.com/Java/Article/30839
Determine Your Java Software's Performance Capacity During Development (Page last updated March 2006, Added 2006-03-29, Author Raghu Donepudi, Publisher DevX). Tips:

• It is not cost effective to do an exact production simulation load test on a pre-production or test environment.
• Initial load test runs are prone to crashing.
• While doing load tests, use this simple query to watch for open cursors: select s.SQL_TEXT , count(*) from v$sql s, v$open_cursor oc where oc.hash_value = s.hash_value group by s.SQL_TEXT having count(*) > 1
• Queries using clauses such as % and ORDER BY tend to demand more CPU time and runtime memory. During low loads these queries do not have much of an effect, but as loads increase they can have a cumulative effect.
• System.out statements put load on the JVM, and on the underlying operating system, and should be removed where not needed.
• max-http-connections configuration controls the maximum allowable HTTP connections. Though the theoretical value is infinite, after a certain number the response time will gradually increase for each request to the server. At this juncture, it is better to have another instance of the server

http://www.javaworld.com/javaworld/jw-03-2006/jw-0313-leak.html
Plug memory leaks in enterprise Java applications (Page last updated March 2006, Added 2006-03-29, Author Ambily Pankajakshan, Publisher JavaWorld). Tips:

• The JVM throws a Java out-of-memory error if it is not able to get more memory in the heap to allocate more Java objects.
• The JVM cannot allocate more objects if the heap is full of live objects and unable to expand further.
• Four causes of memory leaks in a Java program are: Unknown or unwanted object references; Long-living (static) objects; Failure to clean up or free native system resources; Bugs in the JDK or third-party libraries
• Detect memory leaks by: Using a process monitor (e.g. ps or task manager); Use Runtime.totalMemory() and Runtime.freeMemory() methods; Use memory-profiling tools.
• An example of how a memory leak could occur is using pooled JDBC Connection objects. For some pool implementations, closing the Connection does not automatically close the ResultSet and Statement objects.
• It is good practice to explicitly close resources such as ResultSet and Statement objects, rather than expect them to be closed implicitly by some other action.
• Memory leaks can easily occur if items are not removed from a collection when they are no longer needed. This is known as the Leak Collection anti-pattern.
• Avoid referencing shorter-lived objects from long-lasting objects, or use a weak reference to ensure garbage collection can proceed.
• Use of HttpSessions should be minimized and used only for state that cannot be kept on the request object.
• Remove objects from HttpSession when they are no longer used.
• Long-lived data should be migrated to the business tier.

Jack Shirazi Back to newsletter 064 contents