Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers| Heap dump analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Training online: Concurrency, Threading, GC, Advanced Java and more ... 

The Roundup February 28th, 2003

Get rid of your performance problems and memory leaks!

Modern Garbage Collection Tuning
Shows tuning flow chart for GC 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

Get rid of your performance problems and memory leaks!

Back to newsletter 027 contents

The JavaRanch

A question was asked about merging two datasets, one a sorted list, the other unsorted, the result to be sorted. Various solutions were presented: use the Collections.sort(); Insertion sort; Quicksort; Insertion sort plus binary search; sort the unsorted set then merge with mergesort; a custom sorting technique. None of the respondents suggested doing it the easiest way then timing it to see if performance was acceptable BEFORE trying to figure out the quickest way. RTFM. Doh.

Another poster seemed to be asking whether he should use sleep() to reduce the load from his back-end process. A curious question, we were given no idea of what the process was except that it used Tomcat. He later found that his process used 100% CPU, so he inserted sleep(1000) and all was well. Sometimes these discussion threads seem to consist of aliens doing things too esoteric to understand. This guy was either a genius or an idiot. I don't have an opinion which, I admit that I'm ignorant enough to be wrong either way.

The limitations of MappedBuffer, the buffer obtained from mapping files into memory using NIO, came up. The file was very large, and the system (XP in this case) seemed to be taking all the free memory for the file cache to handle the mapping. Other processes were basically swapped out, so switching tasks to another activity was very slow, probably because the system had to page that process back into memory. The poster redeveloped the task without NIO, using RandomAccessFile, and found that the speed was faster, and the problem of swamped memory went away, i.e. other tasks were now responsive. The question was, shouldn't NIO memory mapped files provide better performance? The only response suggested that MappedBuffer's were not necessarily good for random writes. The responder, Toby Reyelts, went on to say "if your mapped file is larger than your actual working memory, and you're performing lots of random write access ... the paging system will constantly be evicting entire pages to disk (even when only a few bits have changed) so it can reload pages that were previously evicted, just to swap them back out to disk again."

For a couple of years, Sun has maintained that object pooling is unnecessary and even detrimental to performance. So a thread looking at object creation and GC, compared to pooling and reusing objects in 1.4.1 looked interesting. The results of the discussion looked to be that reusing objects from a static pool still had a significant edge over creation & GC of objects, at least for some kinds of applications (such as the ray-tracing one tested). In addition, ThreadLocal is much faster in 1.4.1, and Thread.currentThread() is now so fast it's nearly free.

The Server Side

A question asking about EJB Local performance produced only one reply: that Locals are fast because they avoid marshalling overheads.

Another asking about J2EE compliant caching tools produced two vendor replies: eXcelon's Javlin and Tangosol Coherence.

Back to newsletter 027 contents

Last Updated: 2022-06-29
Copyright © 2000-2022 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us