On Nov 19, 2:57 pm, "Daniel Dyer" <"You don't need it"> wrote:
On Mon, 19 Nov 2007 19:28:17 -0000, Java Performance Export
This Java class takes about 15.6 seconds to print 5,000,000 lines or
63,700 lines / sec ... 67 times slower!
Try the Java printf so that you are at least comparing something similar
(it should avoid a lot of the String allocations):
tried it, make it run in over 40 secs instead of 15 seconds.
Also, try the -server switch on the JVM. It may well inline a lot of
those method calls that you are seeing.
had no effect.
Finally, disregard your results until you have considered the following
Java micro-benchmarking advice posted here by Chris Uppal a while back:
<http://groups.google.com/group/comp.lang.java.programmer/browse_frm/t...>
Followed these instructions, moving the "loop" into a separate method,
then called that a number of times. no improvement. Rewritten test
class below. I presume putting the meat of it in a separate method
allows the JIT to recognize it as a bottlneck and use inlining or
native compliation on subsequent invocations? But it did not do
so even after 100 invocations. Can't I just ask Java to compile
the very first one?
W/ the revised class I am also still seeing over 50 methods calling
each other before 80% of the CPU time is accounted for (see origional
post). I would have expected there to be some very small handful of
places where most of the work was done.
Mostly what i am wondering is what the heck are these methods
and why is all this necessary, or is it? and how can I get
this simple program to run as quickly as possible in Java.
Also, I saw comments this is "not a valid benchmark." Actually
this script is being used to pipe test input to a database processing
stream, and it was thought the component of the pipe that simply emits
the test data would be so negligible as to be ignored. However the
factor of ~ 70 slowdown w/ Java version is causing that to be an
issue.
The question I don't want to have to answer is "Why, again, can you
not make this program run fast?"
Thanks,
Larry