HotSpot optimization for large amounts of array use

Question

Greetings all,
I'm hoping some of the people using Java for crypto and/or image processing/media file processing might by wandering by to get some input.
We are building a secured storage system for media files, currently using the Twofish algorithm (one of the AES candidates that wasn't selected). We are bulk encrypting files for entry into the storage system, and in that process, I was already using Java for some of the management. Thus I decided to use the JCE framework to get the cryptography working.
I hate to say it, but this Java evangelist is a bit appalled at how slow it seems to go. By suspicion is the array bounds checking in the code, but I haven't gone byte-code snooping yet. I've tried a few of the symmetric algorithms (DES, AES/Rijndael and Twofish) and get the same sort of results. I've also tried the Cryptix library for the Twofish, as the Sun JCE doesn't have Twofish.
In straight C code, a G4-700MHz and a US-III 750 MHz get around the 20-25 MB/s encoding.
In Java, I'm getting about 1.3-1.9 MB/s. I reduced the Java code to be raw crypto without using the JCE, and it didn't make a noticable difference.
That's a BIG gap. Not 10%, not 20%, but about 95% reduction in performance.
The profiling with -Hprof shows about 90% of the time in the crypto routines, and all of it is compiled via HotSpot.
Settings are with java 1.3.1 on the G4, and 1.4.0_01 on the UltraSparc-III.
Settings were -server -Xmx128m -Xms128m
Does the bounds checking impose that high of a penalty?
Reading the book Java Platform Performance (excellent book BTW), Steve Wilson and Jeff Kesselman indicate that the array checking could be optimized out in certain loop constructs in HotSpot, but that preliminary examination showed that this would only benefit a narrow range of developers.
With JMF, JCE, and the increasing capabilities of Java2D and 3D, I expect that this sort of processing will increase dramatically, but only if this level of performance penalty can be removed.
Anything else I might try?
Dallas

Answer 1

Thanks for the reply. I've been looking into it further, but with no real advance. I've implemented a twofish JNI bridge that runs the actual encryption natively, at pretty much native speeds. The array access and twofish cipher does copy all elements locally, and the rest of the cipher is bit manipulation on bytes. I haven't quite gotten deep enough into the actual cipher to see where the performance penalty is being incurred.
Possibly I'm mistaken in thinking it was the array access, but I didn't expect the raw bit twiddling and bitwise operators to be slow.