Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Do any Java compilers or JVMs optimize getter method calls?

Reply
Thread Tools

Do any Java compilers or JVMs optimize getter method calls?

 
 
david.karr
Guest
Posts: n/a
 
      09-03-2009
I prefer to reference instance variables through getters, as opposed
to direct access to them. However, there's "obviously" going to be a
small time penalty for that. I did some timings in Eclipse, and I
found direct reads were a tiny fraction faster than through the getter
call (no surprise), and the difference between the setter and a direct
write was even smaller (I tested 100000000 iterations, adding up the
nanosecond intervals of each type of access).

I'm wondering whether there are any compiler/JVM combinations that
optimize getter calls to be the same as a direct access? I can see
from the bytecode in Eclipse that there is no optimization at that
level, but I don't know if the JVM will do any optimization in some
cases. It didn't appear to do it in Eclipse, but I don't know if other
JVMs would act differently.
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      09-03-2009
david.karr wrote:
> I prefer to reference instance variables through getters, as opposed
> to direct access to them. However, there's "obviously" going to be a
> small time penalty for that. I did some timings in Eclipse, and I
> found direct reads were a tiny fraction faster than through the getter
> call (no surprise), and the difference between the setter and a direct
> write was even smaller (I tested 100000000 iterations, adding up the
> nanosecond intervals of each type of access).
>
> I'm wondering whether there are any compiler/JVM combinations that
> optimize getter calls to be the same as a direct access? I can see
> from the bytecode in Eclipse that there is no optimization at that
> level, but I don't know if the JVM will do any optimization in some
> cases. It didn't appear to do it in Eclipse, but I don't know if other
> JVMs would act differently.


You cannot tell optimization from the bytecode, because optimization happens
in the JVM.

Doesn't Eclipse use the JVM installed on your system? What JVM is installed
on your system?

What options are you passing to the JVM now?

The most significant optimizations occur with the "-server" option to the
"java" command (or equivalent). Others are possible. They are documented on
java.sun.com and elsewhere.

Methods declared as 'final' tend to be inlined and run faster than methods not
so qualified.

When running your benchmarks, let the loop run a bunch of times before you
start timing. That lets the Hotspot compiler analyze the run and figure out
what to optimize.

The tricky thing with Hotspot is that it might inline or enregister or loop
unroll or compile certain things at some times, then de-optimize them at other
times depending on the moment-by-moment profile of the execution.

The compiler (i.e., "javac") tends to have negligible impact on optimization,
since optimization happens at run time.

--
Lew
 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      09-03-2009
david.karr wrote:
> I'm wondering whether there are any compiler/JVM combinations that
> optimize getter calls to be the same as a direct access?


From a cursory glance at the OpenJDK source code, hotspot does try to
inline accessors.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
David Karr
Guest
Posts: n/a
 
      09-03-2009
On Sep 3, 3:56*pm, Lew <(E-Mail Removed)> wrote:
> david.karr wrote:
> > I prefer to reference instance variables through getters, as opposed
> > to direct access to them. *However, there's "obviously" going to be a
> > small time penalty for that. *I did some timings in Eclipse, and I
> > found direct reads were a tiny fraction faster than through the getter
> > call (no surprise), and the difference between the setter and a direct
> > write was even smaller (I tested 100000000 iterations, adding up the
> > nanosecond intervals of each type of access).

>
> > I'm wondering whether there are any compiler/JVM combinations that
> > optimize getter calls to be the same as a direct access? *I can see
> > from the bytecode in Eclipse that there is no optimization at that
> > level, but I don't know if the JVM will do any optimization in some
> > cases. It didn't appear to do it in Eclipse, but I don't know if other
> > JVMs would act differently.

>
> You cannot tell optimization from the bytecode, because optimization happens
> in the JVM.


Yes, I know, I was just pointing out the bytecode wasn't already pre-
optimized.

> Doesn't Eclipse use the JVM installed on your system? *What JVM is installed
> on your system?


Yes. I've tested with Sun's 1.5.0_19, 1.6.0_14, and 1.6.0_16.

> What options are you passing to the JVM now?
>
> The most significant optimizations occur with the "-server" option to the
> "java" command (or equivalent). *Others are possible. *They are documented on
> java.sun.com and elsewhere.


I wasn't using "-server" before, but I am now. That's a useful
change.

> Methods declared as 'final' tend to be inlined and run faster than methods not
> so qualified.
>
> When running your benchmarks, let the loop run a bunch of times before you
> start timing. *That lets the Hotspot compiler analyze the run and figure out
> what to optimize.


I'm also using both of these strategies. I'm running 100000000 timed
iterations, so I doubt the warm-up loop is necessary, but I'm doing
that anyway.

My measurements show very tiny differences (perhaps .02% total
difference over all 100000000 iterations). In fact, emphasizing the
fact that this isn't statistically significant, I saw several runs
where the "direct" test was slightly slower than the "getter" test.

If it matters, following this is my test class.

------Timings.java----------
package timings;

public class Timings {

private String foo;

final public String getFoo() {return foo;}
final public void setFoo(String foo) {this.foo = foo;}

public static void main(String[] args) {
Timings timings = new Timings(args);
timings.go();
}

public Timings(String[] args) {}

private void go() {

// warmup loop.
for (int ctr = 0; ctr < 1000; ++ ctr) {
setFoo(ctr + "");
getFoo();
this.foo = this.foo + "";
}

int iters = 10000000;

long totalns;

totalns = 0;
for (int ctr = 0; ctr < iters; ++ ctr) {
setFoo(ctr + "");
long startTime = System.nanoTime();
String val = getFoo();
totalns += (System.nanoTime() - startTime);
}
System.out.println("getter[" + totalns + "]");

totalns = 0;
for (int ctr = 0; ctr < iters; ++ ctr) {
setFoo(ctr + "");
long startTime = System.nanoTime();
String val = this.foo;
totalns += (System.nanoTime() - startTime);
}
System.out.println("direct[" + totalns + "]");

totalns = 0;
for (int ctr = 0; ctr < iters; ++ ctr) {
long startTime = System.nanoTime();
setFoo(ctr + "");
totalns += (System.nanoTime() - startTime);
}
System.out.println("setter[" + totalns + "]");

totalns = 0;
for (int ctr = 0; ctr < iters; ++ ctr) {
long startTime = System.nanoTime();
this.foo = ctr + "";
totalns += (System.nanoTime() - startTime);
}
System.out.println("direct[" + totalns + "]");
}
}
--------------------
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-04-2009
On Thu, 3 Sep 2009 15:31:22 -0700 (PDT), "david.karr"
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>I'm wondering whether there are any compiler/JVM combinations that
>optimize getter calls to be the same as a direct access?


this is one of the hotspot optimisations. I takes a while for the JVM
to optimise a routine. It can inline many small routines, not just
getters.

If you want it done immediately, you need static optimisation at
compile time with Jet.
see http://mindprod.com/jgloss/jet.html

--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, itís an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.
 
Reply With Quote
 
Karl Uppiano
Guest
Posts: n/a
 
      09-04-2009


"David Karr" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Sep 3, 3:56 pm, Lew <(E-Mail Removed)> wrote:
>> david.karr wrote:


[...]

> My measurements show very tiny differences (perhaps .02% total
> difference over all 100000000 iterations). In fact, emphasizing the
> fact that this isn't statistically significant, I saw several runs
> where the "direct" test was slightly slower than the "getter" test.


Given the infinitesimal advantage of direct calls, it seems you could focus
your optimization efforts elsewhere to much more advantage. I have always
found that a solid design is much more effective at achieving high
performance than speculative optimization. The exception to this rule would
be if profiling revealed that you were spending an inordinate amount of time
calling getters.

 
Reply With Quote
 
Lothar Kimmeringer
Guest
Posts: n/a
 
      09-04-2009
david.karr wrote:

> I'm wondering whether there are any compiler/JVM combinations that
> optimize getter calls to be the same as a direct access?


As already mentioned this is done by the Hotspot. Maybe the
Hotspot inlines faster, if you declare the getter-method
final. On the other hand, why do you bother with this kind
of optimization? Do you have real performance-problems?

If not, just let it be the way it is (with getters and setters)
and concentrate on something else. I had to solve a couple
of problems and never it was a simple getter that caused the
problem but some inefficient algorithm.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: http://www.velocityreviews.com/forums/(E-Mail Removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
Reply With Quote
 
Lothar Kimmeringer
Guest
Posts: n/a
 
      09-04-2009
Karl Uppiano wrote:

> I have always
> found that a solid design is much more effective at achieving high
> performance than speculative optimization. The exception to this rule would
> be if profiling revealed that you were spending an inordinate amount of time
> calling getters.


And if that is the case, the use of a cached value (assuming
that the getter-method returned the same value all the time)
should be a much better solution than changing the access
from the call of a getter to the direct access of the field.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (E-Mail Removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      09-04-2009
David Karr <(E-Mail Removed)> wrote:
> If it matters, following this is my test class.
> ------Timings.java----------
> package timings;
> public class Timings {
> [...]
> // warmup loop.
> for (int ctr = 0; ctr < 1000; ++ ctr) { ... }


Good, but I'd spend like 100000 iterations to warmup, or even
place two loops ... Probably not more than Voodoo, but I think
it helped in a previous case for me. (I had a loop over the
actual measurement loops, and the first two complete runs of
inner loops took noticeably more time than each of the following
ones)

> int iters = 10000000;
> for (int ctr = 0; ctr < iters; ++ ctr) {
> setFoo(ctr + "");
> long startTime = System.nanoTime();
> String val = getFoo();
> totalns += (System.nanoTime() - startTime);
> }


I wouldn't do it that way, but rather take the nanos before and
after the inner loop. The loop-overhead is probably less than the
time-taking overhead. If it isn't then differences of getter-
timings compared to loop-overhead makes the matter even more moot.

Also, you could make the attribute an int and assign it the current
loop-counter. that will reduce the overhead for generating a new
value to set before getting it.

PS: Since a recent "adventure" with an oracle-sql query, my trust in
automatic optimizations is currently lower than ever. (although java-
optimizations have nothing to do with (absent) oracle-optimizations)

 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-04-2009
On Thu, 3 Sep 2009 16:32:57 -0700 (PDT), David Karr
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>
>Yes, I know, I was just pointing out the bytecode wasn't already pre-
>optimized.


One of the amusing things is if you optimise the byte code it can make
the code SLOWER, because Hotspot and other optimisers don't have the
clutzy standard patterns to recognise.

I poked around quite a bit at the assembler generated by Jet. I was
blown away by what it did. It was faster than any sane human would
write. It took into account not just the official number of cycles
per instruction, but the internal parallelisation of the chips and the
pipelines.

Unfortunately, the Jet people were freaked by this and removed the
tool to display the assembler code. They sell Jet not so much as an
optimiser as an obfuscator. They felt my discussion of how it worked
inside make it look as if it were easy to disassemble, which it most
definitely is not.



--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, itís an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
commercial c compilers vs free c compilers geletine C Programming 33 07-07-2006 05:21 AM
running different plugins within a java application in different JVMs [urgent need of help] dima.alina@gmail.com Java 3 03-09-2006 01:34 PM
running different plugins within a java application in different JVMs [urgent need of help] dima.alina@gmail.com Java 3 02-23-2006 01:07 PM
running different plugins within a java application in different JVMs dima.alina@gmail.com Java 0 02-22-2006 08:28 AM
Communication between Java applications running on different JVMs laura.paterson@gmail.com Java 1 01-05-2005 12:25 PM



Advertisments