You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Loenko <ml...@gmail.com> on 2006/03/10 08:58:07 UTC
[classlib] performance tips
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
Re: [classlib] performance tips
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Mark
2006/3/11, Mark Hindess <ma...@googlemail.com>:
> On 3/10/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >
> > Anyway we can think about redundant initialization as a bad style,
>
> In Java at least, for the natives I submitted a JIRA to fix some of
> initializations in the natives (HARMONY-185). Would you say they are
> redundant there too? Personally I think it's not well-defined in C
> and they should be explicit.
Exactly. What I was talking about was for Java.
Thanks,
Mikhail
>
> Regards,
> Mark.
>
> --
> Mark Hindess <ma...@googlemail.com>
> IBM Java Technology Centre, UK.
>
Re: [classlib] performance tips
Posted by Mark Hindess <ma...@googlemail.com>.
On 3/10/06, Mikhail Loenko <ml...@gmail.com> wrote:
>
> Anyway we can think about redundant initialization as a bad style,
In Java at least, for the natives I submitted a JIRA to fix some of
initializations in the natives (HARMONY-185). Would you say they are
redundant there too? Personally I think it's not well-defined in C
and they should be explicit.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [classlib] performance tips
Posted by Alexey Petrenko <al...@gmail.com>.
2006/3/10, Mikhail Loenko <ml...@gmail.com>:
> Anyway we can think about redundant initialization as a bad style,
I think that all redundant tasks are bad style...
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: [classlib] performance tips
Posted by Mikhail Loenko <ml...@gmail.com>.
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 <li...@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 <Ro...@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
> >
>
Re: [classlib] performance tips
Posted by Arzhan Kinzhalin <li...@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 <Ro...@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
>
Re: [classlib] performance tips
Posted by Robin Garner <Ro...@anu.edu.au>.
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