hex dump?

A

Andreas Leitgeb

Arne Vajhøj said:

Is it just me, or do others feel alike, that the above two
paragraphs contradict each other? ("just let the compiler(JIT)
do it's job" versus "use explicit StringBuilders for loops
instead of s+=...")

PS: leaving aside, that others (excluding me) may consider the explicit
StringBuilder to be just "clear code" in contrast to "s+=...;".

PPS: and surely, the JIT also will never be able to replace a
handcoded bubblesort with a mergesort, so I find this overly
trusting the optimizer to be rather misguided. (of course,
the recommendation for profiling before handoptimizing still
holds.)
 
L

Lew

Andreas said:
Is it just me, or do others feel alike, that the above two
paragraphs contradict each other? ("just let the compiler(JIT)
do it's job" versus "use explicit StringBuilders for loops
instead of s+=...")

It's just you.

Substitution of one class for another altogether across several lines of code
is stretching the definition of the compiler's job.
 
A

Andreas Leitgeb

Lew said:
It's just you.
Substitution of one class for another altogether across several lines of code
is stretching the definition of the compiler's job.

Of course it is! But even more so is believing that the compiler will
*always* make the best of my clear code(*), and that therefore I as a
programmer should *never* worry about performance-tweaks when writing
clear code(**).

*: Unless it is reduced to a tautology where "the best" is defined as what
is within reach of the optimizer-technology in current JIT, rather than
the fastest equivalent code.

**: which is how I understood Arne's (first quoted) comment
 
M

Mike Amling

SpreadTooThin said:
I have a program that receives binary data over udp.
I want to print out the recieved buffer as a bunch of hex digits...
eg: FF FE AB 22 DD

Right now I am doing:

System.out.println(receivePacket.getData())
I should have 102 bytes in the received packet...

byte[] data=receivePacket.getData();
// If receivePacket is a java.net.DatagramPacket,
// then getData returns a byte[].

for (int jj=0; jj<data.length; ++jj) {
int datum=data[jj] & 0xFF;
System.out.print("0123456789ABCDEF".charAt(datum>>4));
System.out.print("0123456789ABCDEF".charAt(datum & 0x0F));
// Optional formatting:
System.out.print(' '); // after every byte
if (jj%4==3) {
System.out.print(' '); // after every four bytes
}
if (jj%16==15) {
System.out.println(); // new line after 16 bytes
}
}

This routine works with all versions of Java (Write Once, Run
Anywhere). It gives the programmer the choice of using upper-case or
lower-case letters for the hex digits representing 10 through 15. It
uses string literals as first-class Objects, which some new converts to
Java find novel.

--Mike Amling
 
A

Arne Vajhøj

Andreas said:
Is it just me, or do others feel alike, that the above two
paragraphs contradict each other? ("just let the compiler(JIT)
do it's job" versus "use explicit StringBuilders for loops
instead of s+=...")

PS: leaving aside, that others (excluding me) may consider the explicit
StringBuilder to be just "clear code" in contrast to "s+=...;".

PPS: and surely, the JIT also will never be able to replace a
handcoded bubblesort with a mergesort, so I find this overly
trusting the optimizer to be rather misguided. (of course,
the recommendation for profiling before handoptimizing still
holds.)

The compiler is not supposed to change the classes you use
or the algorithms you pick.

But the compiler is supposed to take care of stuff like
moving calculation of constant expressions outside the loop,
eliminating necessary tests etc..

Arne
 
A

Arne Vajhøj

Andreas said:
Of course it is! But even more so is believing that the compiler will
*always* make the best of my clear code(*), and that therefore I as a
programmer should *never* worry about performance-tweaks when writing
clear code(**).

*: Unless it is reduced to a tautology where "the best" is defined as what
is within reach of the optimizer-technology in current JIT, rather than
the fastest equivalent code.

**: which is how I understood Arne's (first quoted) comment

I can guarantee you that the compiler will not always make the best
of your clear code.

But that is not the same as to say that it makes sense to hand
optimize.

The JIT compiler practically always does a decent job meaning that
your potential gains are small.

If you make a simple test on your development PC, then the chances that
the code change you make will improve performance in production context
is not much higher than 50%.

If you test different Java versions both vendor and versions, different
platforms, different loads, different hardware etc. then you can
end up with nothing conclusive. And even if you did end up with
something conclusive, then it is most likely not cost effective, because
the time spend could easily have paid for faster hardware.

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top