For uber Java performance you want to eliminate all virtual calls, keep methods small (so they can be inlined and optimized further), you also want to avoid volatile reads and writes as well as avoiding branch-misprediction and L2 trashing, blocking IO and locks.
On Thu, Jul 22, 2010 at 12:43 PM, Reinier Zwitserloot <reini...@gmail.com>wrote: > TL;DR: Your question cannot be answered. Those who are trying are > giving you bad advice. The only way to solve your issue is to run a > profiler on real world data. > > More extensive answer: > > Heh, nice. This is exactly why you shouldn't ask these questions. > Alexey Zinger's comment that i++ is slower than ++i is exactly the > kind of completely wrong micro optimization bullpuckey you get when > you do. > > This is java, it's not C. The answer depends on use case, behaviour, > java version, hot spot compiler, OS, environment, alternate load, and > a few other things. Therefore, your original question: "What's the > fastest way to do X in java" is simply impossible to answer. > > The right way to handle this situation is to measure a complete use > case. Do NOT micro benchmark. Run a real profiler, on real-world > representative data, in a real world situation (i.e. run a music > player and a webserver that's being actively pinged if that's the > situation that's likely when performance counts). As a practical > matter, and going mostly by gut instinct, most of the things you said > (such as, should I go by stream) don't really work; how do you think > that stream class reads bytes from the array in a way that avoids a > generated bounds check? It won't. > > Also, if this is for android, well, that's another beast altogether. > There's no actual bounds check in class files, the JVM inserts it when > running your class file. Android takes class files and rewrites it > into dalvik opcodes. Who knows if dalvik optimizes array bounds > checks? Also, when you say that some optimization such as bound check > reduction wasn't added because it barely made a difference then.. > well, experts say it barely makes a difference. That's better advice > any of us on this list could possibly give you! > > > On Jul 21, 4:18 pm, Alan Kent <alan.j.k...@saic.com> wrote: > > I was wondering what the fastest way (most highly performant) was to > > parse data structures serialized as an array of bytes. In my case its > > like a network packet (a true array of bytes where I need to peel of 1, > > 2, 4, and 8 byte integers, or variable length ASCII (8-bit) strings, > etc.) > > > > Note I am after the FASTEST way to do this in Java (and/or Scala). Is > > it better to use the stream based classes, or is it better to do direct > > array accesses and do bit shift operations and masks with 0xff etc (to > > strip sign extension Java will do otherwise)? I suspect the stream > > based approaches would be slower. Sample code that sneaks in: > > > > byte b1 = buf[i++]; > > byte b2 = buf[i++]; > > byte b3 = buf[i++]; > > byte b4 = buf[i++]; > > int n = (b1 << 24) | ((b2 & 0xff) << 16) | ((b3 & 0xff) << 8) | (b4 > > & 0xff); // Must mask with 0xff or else sign extension will mess up the > > result. Java does not have unsigned bytes or ints! > > > > I was looking into array bounds checks, and what I found via Google > > indicated that hotspot leaves in array bounds checks as there was only a > > minor performance improvement found in practice. This lead me to wonder > > if there is a faster way to do the code since I would be doing lots of > > array accesses, each with a bounds check. > > > > Just curious! > > > > Thanks! > > 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 javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Viktor Klang | "A complex system that works is invariably | found to have evolved from a simple system | that worked." - John Gall Akka - the Actor Kernel: Akkasource.org Twttr: twitter.com/viktorklang -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
