GeeCON Prague 2014*
The moose likes Performance and the fly likes using temporary variabel Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Performance
Bookmark "using temporary variabel" Watch "using temporary variabel" New topic
Author

using temporary variabel

blingo james
Greenhorn

Joined: Oct 12, 2008
Posts: 25
Hello,
Wanted to see if using temproary variabels, changes the preformances (even by a little).
from what I see, the bytecodes (attached below the relevant parts) produced when using temproary variabels is longer,

1) does it mean it's also slower, or am I missing something?

2) is there a why to tell the javac (or Eclipse, which is what I'm using), to produce more optimized code?

3) does those two look the same on Jit? does Jit runs automaticaly or do I have to turn it on?
(and for that matter, how can i see the Jit code?)

Many Thanks.

(b.t.w the code looks really nice here )






Omar Al Kababji
Ranch Hand

Joined: Jan 13, 2009
Posts: 357
Well what i can say is that the compiler should have some intelligent mechanism for optomizing the generated code for example if you have a code like this one:



then the compiler should make it like this:




however how much optomization is done i really don't know

(peace)

Omar Al Kababji - Electrical & Computer Engineer
[SCJP - 90% - Story] [SCWCD - 94% - Story] [SCBCD - 80% - Story] | My Blog
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 417
    
    2

I suspect the optimisation isn't legal Java rather than something the compiler would do , I suspect for instance System.out.println acquires a lock and if x and y where non local than you need to be a ' java language lawyer' as to if moving x and y reads over a sequence point is valid or not (I'm not saying it isn't valid in this case (I haven't checked) I just suspect its not) as an example of why your compiler might not wish to do such a thing.


"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

I'm not sure whether omar's example is a legal optimization or not, but note that it's a space optimization only; the performance would of course be the same.

In blingo james' example, the only real extra instructions are the computed values being stored into local variables, then immediately fetched out. That is precisely the kind of thing that the Hotspot engine can, and does, optimize away, so that the temporary variables will not, ultimately, hurt the performance.

You can't normally see the native code that Hotspot generates, but you can if you install a special debug build of the JDK. See this very cool blog entry for the info.


[Jess in Action][AskingGoodQuestions]
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11351
    
  16

blingo james wrote:
from what I see, the bytecodes (attached below the relevant parts) produced when using temproary variabels is longer,

1) does it mean it's also slower, or am I missing something?

I don't think you can say that just because the byte code is longer, it's slower. For example:

to get from St. Louis to Kansas city:
1) get on highway 70 wesbound
2) drive until you get to Kansas city.

To get from the Library to my house:
1) Go east on Washington
2) turn left on Ballas.
3) turn right on Crescent
4) Stop at my house.

Now, there are twice as many direction in the second case, but the trip itself is significantly shorter.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Omar Al Kababji
Ranch Hand

Joined: Jan 13, 2009
Posts: 357
Hi, what i meant by optimizations done by the compiler is that it will adjust the order of how instructions are executed of-course it will not make them at the level of the Java language however i am pretty sure they will be done at a low level for example at the bytecode, where it will find that a group of instructions could be reordered without having side effects.
Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5835
    
    7

Counting bytecode is a poor way of determining performance because the bytecode is not the final arbiter of what gets run. Eventually the just-in-time (JIT) compiler gets hold of it and converts it to machine instructions, and the JIT employs numerous optimization techniques. Thus it is the final machine ops that really determine the performance. (Yes I know that most JVMs typically interpret bytecode several times before deciding to JIT it, but if you run through a piece of code only a handful of times then trying to optimize that code is an exercise in futility.)


JBoss In Action
blingo james
Greenhorn

Joined: Oct 12, 2008
Posts: 25
Sorry for the late reply,

Thanks anyone for contributing,

After trying to study this with the help of your guidelines,
My conclusion on the subject:

All Java is transformed to bytecode with virtually no optimization.
When classes are executed by the JVM, each bytecode line is interpreted, and no optimization is done here.

Optimization only kicks in when the JIT in the JVM starts to work, and that happens when it sees loops, or when code is executed over a number of times, and the more times it is executed, the more JIT will optimize it.

That means that without JIT (and JIT can be disabled) Java code executed by the JVM is not (per-code-specific) optimized at all.

Interesting effect is that if you are running a loop only several times, It would probably not be optimized to the same degree, had it been looped for a large number of times.

* special thanks to Ernest Friedman-Hill for pointing me to that cool blog entery - it changed the way I think about Java .
Been trying to understand what the code produced by JIT means, someone pointed me towards OpenjDK for further study.
 
Don't get me started about those stupid light bulbs.
 
subject: using temporary variabel