Are each of the 4 groups of 8 bits likely to be signed? if not, you
could perhaps 'or' together the first three, then perhaps only the
last needs to be 'anded' with FF?
I don't know where your getting your data from, but wonder whether 3/4
of them are unsigned?
Certainly don't hold temporary variables inside the loop, the static
method sounds better, although I don't know how many invocations will
be made before it is in-lined; perhaps you should copy the code in-
line to be sure?
Cheers
Rob Wilson
On Jul 21, 9:58 pm, mikeb01 <mike...@gmail.com> wrote:
> If you care about speed put together a good set of performance tests
> to measure what you're doing.
>
> On the specific example you could avoid some of the intermediate
> variables and a few implicit widening operations (however hotspot will
> probably optimise this for you). Probably drop it into a static
> method for a bit of reuse:
>
> public static int toInt(byte[] buf, int offset) {
> return (buf[offset] & 0xFF) << 24 + (buf[offset + 1] & 0xFF) <<
> 16 +
> (buf[offset + 2] & 0xFF) << 8 + (buf[offset + 3] &
> 0xFF);
> }
>
> There are a whole bunch of these methods in java.io.Bits (package
> protected) which may help with your implementation.
>
> Mike.
>
> On Jul 21, 8:38 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
> wrote:
>
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
>
> > > 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.
>
> > I think you have to try and measure. I've faced the same problem with
> > image decoding. The ImageI/O API contains an ImageInputStream which is
> > supposed to have some optimizations - even for bitwise, not only
> > bytewise operations. When I first worked on it a few years ago, I
> > found that writing some specific classes for specific cases (e.g.
> > reading 12 or 16 bits) was faster - in other words, the library didn't
> > provide the faster code. A few time later, I discovered that some
> > newer JRE was better and dropped some of my code because it was
> > useless. So, it's a matter of trying, measuring and re-measuring for
> > each JRE update.
>
> > - --
> > Fabrizio Giudici - Java Architect, Project Manager
> > Tidalwave s.a.s. - "We make Java work. Everywhere."
> > java.net/blog/fabriziogiudici -www.tidalwave.it/people
> > fabrizio.giud...@tidalwave.it
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
> > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>
> > iEYEARECAAYFAkxHTLUACgkQeDweFqgUGxcwxACeLpaYIPiaCCWZe4Q+mSPl4P6x
> > DMUAn2+o7vmQ32CxIcB+QobTB6Vov4ek
> > =F5Co
> > -----END PGP SIGNATURE-----
--
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.
