harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arzhan Kinzhalin" <lil...@gmail.com>
Subject Re: [classlib] performance tips
Date Fri, 10 Mar 2006 10:06:52 GMT
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