Arndt Brenschede wrote:
> well, no doubt that these numbers are correct,
> but you have to be careful to draw any conclusion,
> because most probably you found a difference
> between "nano" and "micro" and you may loose the
> overview to find the "millis"...
No, we're talking (on my machine) 15 milliseconds vs. ~2 seconds - the
interface test takes noticeably longer than the other two. If that is not
significant, I don't know what is.
Of course any I/O or even a simple allocation will totally throw this off
- no doubt, but that was not the point. The point is that this deficiency
is a constant, ever present factor, regardless of what your program does.
It is _exactly_ these 'small things' that make Java slow(er) at the end of
the day. Yes, the libraries are outrageously bad; people need additional
library layer cake to make up for them; memory allocation and GC is not
customizable enough, and so on. _None_ of that justifies such a
performance gap at the lowest level.
Crap is not excusable just because you don't see it.
> That's why serious performance tuning should
> be driven by profiling results... :-)
Yes, but for profiling at different levels you obviously need appropriate
tools, and the usual Java profilers do not measure the VM or language
side-effects but only the effectively executed bytecode instructions,
relative to the application's usage. They cannot make any objective
statement about the internal effectiveness of the VM on the target CPU,
like differences in pipeline or cache pollution between invokevirtual and
invokeinterface. For that you'd need Vtune or a synthetic CPU emulator.
The differences that can be achieved by microtuning can be _astounding_
and are usually horribly underestimated, even when the obvious strategies
(algorithm, hardware..) have been applied.
Holger
This archive was generated by hypermail 2.0.0 : Sat Mar 22 2003 - 11:39:11 EST