This is not a valid performance analysis.

You didn't mention "and that's when the hotspot compiler kicked in"
even once, for example.

On Jul 28, 6:56 am, Alan Kent <[email protected]> wrote:
> 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.

Reply via email to