Reply to thread

Message

[QUOTE="Lew, post: 2847212"]
The line-by-line production may not make the best use of
a) object-oriented design principles,
b) other Java idioms.

That could negatively impact performance, especially if the "identical 
results" included copying any bugs.

Java also has multiple optimization options relating to hotspot compilation 
and garbage collection.  Realistic benchmarking would require simulating the 
typical data load between the two versions.  What is typical?  That is 
non-trivial, as is the game of simulating it.

Also, Java's architecture favors long-running processes within an established 
JVM; JVM startup is a significant time eater.

A third contender should be a Java rework of the original algorithm rather 
than the original code, or possibly a substitution of a better algorithm.

The problem here is to give the customer information that will actually 
benefit them, and products that actually serve them.  Coughing up a meager 
translation of a FORTRAN program to Java, then running meaningless benchmarks 
to try to figure out if you did anything useful is a huge disservice to your 
customer.

Make sure the benchmarks measure something that has actual importance, and 
make sure the work has real benefits to the customer.
[/QUOTE]

Verification