Have you tried inlining those methods in your benchmark (no field references, as was mentioned -- just local variables).
Alexey 2001 Honda CBR600F4i (CCS) 2002 Suzuki Bandit 1200S 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net ________________________________ From: Alan Kent <[email protected]> To: [email protected] Sent: Wed, July 28, 2010 12:56:05 AM Subject: Re: [The Java Posse] Re: Fastest way to parse data out of array of bytes? In case anyone cares, did a bit of testing and found: (1) Running in Eclipse using "Run" was about 3 times slower than running "java" on command line (on my particular machine) on the same class files. So yes, environment, JVM version etc make a BIG difference straight up. (2) If you want to write a class reading from a stream with a field holding the current index being read from and you want to read 4 bytes, its faster to update index once than updating 4 times. class ByteBuf { private int i = 0; private byte[] buf = ...; int slowerReadInt32() { byte b1 = buf[i++]; byte b2 = buf[i++]; byte b3 = buf[i++]; byte b4 = buf[i++]; return (b1 << 24) | ((b2 & 0xff) << 16) | ((b3 & 0xff) << 8) | (b4 & 0xff); } int fasterReadInt32() { byte b1 = buf[i]; byte b2 = buf[i+1]; byte b3 = buf[i+2]; byte b4 = buf[i+3]; i += 4; return (b1 << 24) | ((b2 & 0xff) << 16) | ((b3 & 0xff) << 8) | (b4 & 0xff); } } Upon reflection of course it will be faster. The first function has to update the field 'i' per increment in case there is an index out of bounds exception. The second only updates the field once. Doing Google searches on Java vs C++ performance I found some Wikipedia etc pages, that I don't trust much. There were a few subjective sounding statements in there, and some comments talked about the new JIT that might speed Java up. The only comments I almost trust were Java probably does new/delete faster than C++ but tends to consume more memory, and Java JIT might get code to same raw execution speed to same as C++ (but 4 times slower is not unexpected). So my next meaningless microbenchmark will be to try Scala with lazy vals pulled from a byte[] (and so potentially avoiding the need for converting bytes in a buffer into int's in the first place). Alan -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
