This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: benchmark result
Mathieu Lacage writes:
> On Mon, 2004-12-06 at 13:56 +0000, Andrew Haley wrote:
> > We could improve the performance of these collection classes with
> > little work. What is required is someone to study the code, do some
> > profiling, and fix things.
>
> Ok, I did a bit of that. I used the attached trivial benchmark with
> 500000 iterations. On my pentium4, with
> "/opt/gcc-4.0.0/bin/gcj -gdwarf-2 -O3 -mtune=pentium4
> MainArrayBench.java --main=MainArrayBench -o bench"
Thanks.
> I reliably get:
>
> [mlacage@chronos home]$ time -p ./bench 5000000
> sum: 1642668640
> real 2.62
> user 2.30
> sys 0.22
>
> Then, I modified slightly ArrayList to include its own implementation of
> Iterator which accesses the data member directly without doing through
> the ArrayList getter but which does all the checking implemented in
> AbstractList.Iterator (basically, copy/paste AbstractList.Iterator and
> replace get(pos++) with data[pos++]. A sample of that is also attached
> to this email). I reliably got:
>
> [mlacage@chronos home]$ time -p ./bench 5000000
> sum: 1642668640
> real 2.53
> user 2.16
> sys 0.24
>
> I doubt you could get much better results and keep the specified
> semantics of the iterators. Well, it should be possible to inline the
> iterator methods directly in the iterator caller but that would involve
> knowledge of the iterator implementation in the iterator clients which
> is something I cannot imagine possible in the current gcc codebase.
> Maybe the linker could help...
It's not exactly impossible, but it is tricky. I wonder if the
iterator and all its methods can be final, but still conform to the
spec? That would, at least, allow all the checkMod() calls to be
inlined.
Andrew.