Re: Streamtokenizer
"Bryce McKinlay" <[email protected]>
| Newsgroups | gmane.comp.gcc.java.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, May 8, 2008 at 3:14 PM, OneGuy <[email protected]> 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.