Maybe we should stop trying to give advice, apart from "Benchmark it in a real world scenario". The virtual calls could (and probably would) still be inlined if the VM can determine that it's possible. If not now, then probably in the next VM update. Roel
Van: [email protected] [mailto:[email protected]] Namens Viktor Klang Verzonden: 22 July 2010 13:04 Aan: [email protected] Onderwerp: Re: [The Java Posse] Re: Fastest way to parse data out of array of bytes? 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 <[email protected]> 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 <[email protected]> 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 [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. -- 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 [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.
