harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib] performance tips
Date Fri, 10 Mar 2006 10:28:53 GMT
I have discovered this issue when I was investigating why
my implementation of I don't remember what demonstrates
10x worse performance then I expected.

I had a class with empty constructor and a dozen of private fields
initialized by null.

I used JRockit 1.5 - rather a modern VM.

AFAIK JLS does not require additional bytecodes but the task
of optimizing away is not that simple in general

Anyway we can think about redundant initialization as a bad style,
like unused imports or never-read local variables.

Thanks,
Mikhail

2006/3/10, Arzhan Kinzhalin <lilcue@gmail.com>:
> Mikhail,
>
> It's great that we consider performance of the API lib. Let me give
> you just a couple of things to keep in mind in addition to your
> observation.
>
> Firstly, it all depends on the VM implementation which executes the
> code. For modern VMs, bytecode is far from what is actually executed,
> unless you force a VM to interpret. A JIT compiler may eliminate
> exessive bytecodes. For instance, it would be natural for a VM to
> allocate space for an object and fill it with zeroes which yeilds
> Java's default field values. JIT may rely on it and throw away
> explicit initialization to default values.
>
> Secondly, even if both allocation mechanism and JIT are not very smart
> or if the VM interprets the bytecode, consider the case when test is
> only created once during application lifecycle. Impact would be about
> zero. On another hand, if creation of test objects takes, say, 70% of
> the application execution time, optimization of the constructor would
> give dramatic improvement.
>
> So, your suggestion could give from zero to a few tens percent boost.
> In order to determine how much exactly, we need a context. Context is
> always required when performance is questioned.
>
> Thanks,
> Arzhan
> Intel Middleware Products Division
>
> On 3/10/06, Robin Garner <Robin.Garner@anu.edu.au> wrote:
> > Mikhail Loenko wrote:
> >
> > >Hello
> > >
> > >May be it is obvious and everybody knows it from babyhood, but anyway...
> > >
> > >Everybody knows that this two examples of code do the same:
> > >class test {
> > >    public Object field = null;
> > >}
> > >
> > >and
> > >
> > >class test {
> > >    public Object field;
> > >}
> > >
> > >But if you disassemble these two classes, you'll see that the first example
> > >has a 6 instruction constructor:
> > >
> > >   0: aload_0
> > >   1: invokespecial #1; //Method java/lang/Object."<init>":()V
> > >   4: aload_0
> > >   5: aconst_null
> > >   6: putfield #2; //Field field:Ljava/lang/Object;
> > >   9: return
> > >
> > >while the second one has only 3 of them:
> > >   0: aload_0
> > >   1: invokespecial #1; //Method java/lang/Object."<init>":()V
> > >   4: return
> > >
> > >So having explicit assignments of default values slows down constructor.
> > >
> > >Thanks,
> > >Mikhail
> > >
> > >
> > Mikhail,
> >
> > Is this something a bytecode compiler should be able to optimize away,
> > or is there something in the JLS that requires the additional bytecodes
> > to be generated ?  Have you measured the impact (I suspect it is
> > negligible).
> >
> > cheers
> >
>

Mime
View raw message