|
|
|
Back to newsletter 027 contents
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.
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