Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8832 > unrolled thread

Getter performance

Back to article view | Back to comp.lang.java.programmer

Contents

  Getter performance Aéris <aeris@imirhil.fr> - 2011-10-15 23:03 +0200
    Re: Getter performance Arne Vajhøj <arne@vajhoej.dk> - 2011-10-15 17:36 -0400
      Re: Getter performance Arne Vajhøj <arne@vajhoej.dk> - 2011-10-15 17:42 -0400
        Re: Getter performance BGB <cr88192@hotmail.com> - 2011-10-15 15:00 -0700
          Re: Getter performance markspace <-@.> - 2011-10-15 15:20 -0700
            Re: Getter performance David Lamb <dalamb@cs.queensu.ca> - 2011-10-20 12:45 -0400
              Re: Getter performance Roedy Green <see_website@mindprod.com.invalid> - 2011-10-21 14:27 -0700
                Re: Getter performance Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-21 18:57 -0700
                  Re: Getter performance Patricia Shanahan <pats@acm.org> - 2011-10-22 07:27 +0100
                  Re: Getter performance Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-22 09:57 -0300
                Re: Getter performance Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-21 22:12 -0400
                  Re: Getter performance BGB <cr88192@hotmail.com> - 2011-11-13 10:14 -0700
                    Re: Getter performance Lew <lewbloch@gmail.com> - 2011-11-13 11:00 -0800
                Re: Getter performance Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 16:09 -0500
      Re: Getter performance Aéris <aeris@imirhil.fr> - 2011-10-15 23:59 +0200
        Re: Getter performance Arne Vajhøj <arne@vajhoej.dk> - 2011-10-15 19:44 -0400
          Re: Getter performance Aéris <aeris@imirhil.fr> - 2011-10-16 13:14 +0200
            Re: Getter performance Lars Enderin <lars.enderin@telia.com> - 2011-10-16 16:28 +0200
    Re: Getter performance Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-16 09:47 -0400
    Re: Getter performance Jaap Droogers <JaapDroogers@unusable.meel.homelinux.net> - 2011-10-16 22:12 +0200
      Re: Getter performance BGB <cr88192@hotmail.com> - 2011-10-16 13:58 -0700
      Re: Getter performance David Lamb <dalamb@cs.queensu.ca> - 2011-10-20 12:51 -0400
        Re: Getter performance Paul Cager <paul.cager@googlemail.com> - 2011-10-21 08:49 -0700
    Re: Getter performance Roedy Green <see_website@mindprod.com.invalid> - 2011-10-21 08:02 -0700
    Re: Getter performance Wanja Gayk <brixomatic@yahoo.com> - 2011-10-22 21:11 +0200

Page 2 of 2 — ← Prev page 1 [2]

#8871

On 10/16/2011 1:12 PM, Jaap Droogers wrote:
> On 15-10-11 23:03, schreef Aéris:
>> Hello everybody.
>>
>> I work on an application where performances are important.
>>
>> To optimize it, I thought a direct access to a variable (foo.bar) would
>> be more efficient than a getter call (foo.getBar()).
>> I thought by avoiding the call to a method and all that goes with it
>> (context switching, stacking, return value…), I can save time, but this
>> code sample prove the contrary :
>> http://pastebin.com/bP1nqxce
>> Direct variable access : 1041 ms
>> Getter call : 556 ms
>>
>> The difference is even more important if I don't modify the variable
>> value (lines 29 and 36 commented) :
>> Direct variable access : 95 ms
>> Getter call : 4 ms
>>
>> How can we explain this not obvious huge difference ( 50 and 95% ) ?
>>
>
> You forgot the JIT compiler. All the nice clean code you have written is
> optimized by the compiler. You don't write C code, remember.

note:
many C and C++ compilers will perform the same optimization in many 
cases. some compilers will require both to be present in the same 
compilation unit, but some others (such as GCC and LLVM/Clang) can make 
use of link-time optimization.

these sorts of optimizations are nothing specific to the JVM.


> Why is Java so fast: it uses the JIT compiler which optimizes the code
> for the machine the program is running on.
> if you write
> int a = myObject.getA();
>
> the compiler compiles it probably as:
> int a = myObject.a;
>
> There is also a change that you try to optimize your code and the JIT
> compiler does not now how to optimize it, so your code runs slower.
>

yep.

at the CPU level the reference may potentially compile down to a single 
"mov" instruction.

if the getter is called but its value isn't used, then there is a chance 
that it may be discarded altogether (so no CPU instructions are produced 
in this case).

if trying to micro-benchmark or micro-optimize things (yes... including 
in C), one will usually spot this case by the running time dropping to a 
very small number (IOW: the code runs impossibly fast).


generally though, it is not really productive to worry about 
micro-optimizing things. better IMO to leave optimizing for when and 
where it actually matters.

[toc] | [prev] | [next] | [standalone]

#9036

On 16/10/2011 4:12 PM, Jaap Droogers wrote:
> On 15-10-11 23:03, schreef Aéris:
>> The difference is even more important if I don't modify the variable
>> value (lines 29 and 36 commented) :
>> Direct variable access : 95 ms
>> Getter call : 4 ms
>>
>> How can we explain this not obvious huge difference ( 50 and 95% ) ?
>
> You forgot the JIT compiler. All the nice clean code you have written is
> optimized by the compiler. You don't write C code, remember.
> Why is Java so fast: it uses the JIT compiler which optimizes the code
> for the machine the program is running on.
> if you write
> int a = myObject.getA();
>
> the compiler compiles it probably as:
> int a = myObject.a;

Yes, and... thats why you need to do the loop thingy already mentioned: 
you have to amortize the JIT expense over many calls.

Which also, if I understand things correctly, means that the first time 
you do almost anything in a Java program, it's much slower than the Nth 
time (for some value of N). I sometimes see programs where bringing up a 
menu the first time seems to take forever, while the 2nd is faster; is 
that due to the JIT having to run each time I invoke the program?

[toc] | [prev] | [next] | [standalone]

#9069

On Oct 20, 5:51 pm, David Lamb <dal...@cs.queensu.ca> wrote:
> Yes, and... thats why you need to do the loop thingy already mentioned:
> you have to amortize the JIT expense over many calls.

Yes, the benchmark doesn't let the code "warm up" before measuring.

It is also worth pointing out that  within the loop being measured,
there is a call to rand() which is:

  public static String rand() {
    return new BigInteger(130, random).toString(32);
  }

I expect what we are really measuring here is the performance of
SecureRandom and BigInteger - the previous comment about pennies and
bulldozers was good.

http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html
is a really useful page when writing micro-benchmarks.

[toc] | [prev] | [next] | [standalone]

#9068

On Sat, 15 Oct 2011 23:03:51 +0200, Aéris <aeris@imirhil.fr> wrote,
quoted or indirectly quoted someone who said :

>To optimize it, I thought a direct access to a variable (foo.bar) would
>be more efficient than a getter call (foo.getBar()).

Hotspot inlines getters, but not right away.  It interprets the code
for a while to monitor it. If you measure a very short running program
you will not see any optimisation effects. 

Jet also inlines getters. 
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [prev] | [next] | [standalone]

#9092

In article <4e99f537$0$623$426a74cc@news.free.fr>, aeris@imirhil.fr 
says...

> How can we explain this not obvious huge difference ( 50 and 95% ) ?

Basically you don't want to test things like "getter" vs "field access", 
but if you do, then don't test it with a microbenchmark, but set up a 
real world test on your application with realistic data and typical 
runtime, measure carefully, think about the lack of timer-precision 
(System.currentTimeMillis() has a variance of almost 10 ms on some 
operating systems), JIT-compiler-overhead, operating system caching, 
synamic compiler optimizations and stuff like that. Testing such things 
is very hard, way harder than you might initially think!

This should get you an idea:
http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html

When performance is important, get a profiler, such as "yourkit" or 
"jprofiler" and measure instead of guessing. Use that tool to measure 
your current application not some flawed microbenchmark.
If you have successfully pinpointed the real performence bottlenecks in 
your application, always start with the most serious ones.
First think about possibilities to _avoid_ them, such as changing the 
algorithm. Oh yeah, and if you think about eliminating object creation 
overhead, please mind that pooling and re-using objects may actually 
cost you more than it saves you when it comes to garbage collection. 
Most objects are cheap to create and objects that die young are easy to 
collect. If you make them live too long, they can make it into the "old 
generation" only  to get collected by an algorithm that is tuned for 
cleaning out memory that has only few dead objects in it and doesn't 
like too many objects that are doomed to die soon.

Last but not least, very important: Only optimize if there's a real need 
for optimization. As soon as your application meets the performance goal 
("best possible" is not a sane goal) you're fine. Don't waste cash on 
saving the user half a tenth of a second for getting the result of his 
button click. That would be just stupid.
If you can replace a thousand dollars worth of programming effort by 
sticking a few dollars more memory into your server, forget about tuning 
your application, buy the RAM, it's cheaper.

Kind regards,
Wanja

-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web