On Thu, Jul 22, 2010 at 1:35 PM, Roel Spilker <[email protected]> wrote:
> So: If you are woried about performance, make sure you use a > state-of-the-art VM. > > Definitely that's good advice, but that's only one part of the equation, then you have to give it the optimal settings, and then your code needs to be tuned accordingly. And, as always with performance optimizations: profile, tune, profile > ------------------------------ > *Van:* [email protected] [mailto:[email protected]] *Namens > *Viktor Klang > *Verzonden:* 22 July 2010 13:21 > > *Aan:* [email protected] > *Onderwerp:* Re: [The Java Posse] Re: Fastest way to parse data out of > array of bytes? > > > > 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]<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.
