Replying to lots of different emails in one (sorry if got attribute
messed up!)
On 22/07/2010 1:42 AM, Steven Siebert wrote:
Just ensure you get the correct answer for your situation, when you
say a lot of access, do you mean read-only or r/w? Concurrency a
concern? You say you're looking for the fastest...but do you have any
memory limitations to be concerned about?
Single threaded. Might pass different blobs off to different threads to
be processed, but each blob would be parsed by a single thread. So no
concurrency concerns. The result of decoding might be handed off to
other threads to process.
Best analogy is writing a server in Java receiving binary encoded
packets. Need to decode packet read from a stream (socket), decode it,
do some work (one packet might be able to be spawned off into multiple
requests done by different threads), the formulate a response packet and
send it back. (I am not actually reading from a socket in my case - its
coming from files). But primary interest is decoding a packet. Also
interested now you mention it to build up a new packet to respond. But
it would be read and pull apart, or write and build up a new one (not
both at same time).
Someone wrote: about buf[i++] versus buf[++i]
I would hope the JRE would be able to optimize things so there is no
real difference here? For buf[++i] I would have to start i at -1, which
feels a bit funny. A loop looking for the end of the packet would also
be a bit strange (while (i + 1 < buf.length) instead of while (i <
buf.length)).
Rob wrote:
> 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?
For a 32-bit integer, since its an array of byte (which is signed) you have to worry about
the signed value for 3 of the 4 bytes. The most significant byte you don't have to worry
about the sign of because the<<24 shifts the sign off the end of the integer (right
fills with zeros). The<< operator upcasts the byte to integer before the shift
occurs, which is when the sign extension occurs.
I don't know where your getting your data from, but wonder whether 3/4
of them are unsigned?
Its an arbitrary 32-bit integer, so when spliced into bytes I have no guarantee
the individual bytes are signed or not.
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?
Do you know that local variables inside a loop are slower? I would have assumed with
all the cleverness of the JRE that would have been optimized out! I was hoping
the&0xff would also be optimized out with the assembler using unsigned
byte->int conversions (rather than signed extension functions).
Yes, I would rather use methods not repeat the code. Have to do the operation
say a hundred times - certainly don't want to repeat the code all over the
place!
Someone wrote: java.io.Bits
java.io.Bits! I did not know of that one, thanks. Will have a look. Hmm, seems to be doing
pretty much the same thing as my code, but using offsets of +1, +2 etc instead of ++.
Interesting... I never realized there was a>>> operator in Java! (Unsigned shift.)
There is no<<< operator, but its not the shift that is an issue anyway - its the upcast
from byte to int.
Fabrizio wrote:
So, it's a matter of trying, measuring and re-measuring for each JRE update.
Hmmm. That is exactly what I was hoping NOT to hear!!!
Thanks everyone for comments!
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.
