On Thu, Jul 22, 2010 at 1:11 PM, Roel Spilker <[email protected]> wrote:
> 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. > Absolutely, however, how many Java devs are developing their software for future VMs? In the future perhaps the entire code will be after-compiled by an artificial intelligence in the cloud... What I listed are things that _today_ affect performance (if we're talking about millions of operations per second), not a look that gets completely unrolled. There is merit to your words, but I think we should take a minute to reflect on the VMs that are out there, running code, today. A lot of them are still on Java 1.4 or 5. > > 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]<javaposse%[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]<javaposse%[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]<javaposse%[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.
