Streamtokenizer

[Bryce McKinlay]

On Thu, May 8, 2008 at 3:14 PM, OneGuy <oneguyks@gmail.com> wrote:

>  I was testing a 14 MB file with this benchmark,
>
>  http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=java&id=2
>
>  and it turns out that GCJ is 7 times slower than Java6. Can this be
>  called a bug in GCJ 's Streamtokenizer?

Not really - the issue here is most likely that StreamTokenizer, by
design, reads the underlying Stream/Reader one byte at a time using
read(), which is pretty inefficient. The function call overhead
dominates. Java 6 has an advantage here over GCJ AOT compilation
because its JIT (particularly in server mode) can inline all those
calls. This advantage gets more significant with large data sets, as
the JIT has more time to optimize and recompile the code.