Speed of execution
I have a question concerning the speed of my java code. Since this is my first post on this forum I hope you all can forgive me if a should have posted this question somewhere else on this forum.
The question is:
What is more effective in terms of speed of execution: To use an extra if statement, or to use an extra && in the if statement you already have?
In other words, would the following code
if(one==null)
{
if(two==null)
{
do();
}
}
be faster or slower then the code
if(one==null && two==null)
{
do();
}
[1077 byte] By [
Wyrlina] at [2007-11-26 19:38:55]
The chances are not bad that the compiler turns both into identical bytecode.
And even if it doesn't, the difference in speed is going to be so small as to be almost imperceptible. Don't waste your time looking for efficiency differences here. Rather, write your code so that, whatever it's doing, it's obvious what it's doing.
But if you really care about the difference between the two code snippets you posted....then write some test code, and then write a test case that runs each about a million times, or disassemble the code using javap to see what the bytecode instructions are. Maybe you'll see a difference, but I doubt it.
The evaluation of the sub-expressions of an expression with || or && by definition stops when the outcome is already deductible. That it is in our case,
if(one==null && two==null) {
// etc.
}
if (one != null), then the AND expression can not be true, so the second part does not get evaluated. It is a valuable heritage from good old C.
So it is safe to write something like this:
if (list != null && 0 < list.size()) {
//...
}
no NullPointerException wil be thrown even if list happen to be null.
That's true, but the same is true of nested if statements.
Consider this little test class:public class NullTest {
private static Object one;
private static Object two;
public static void test() {
if (one == null)
if (two == null)
func();
if (one== null && two == null)
func();
}
private static void func() {}
}
The generated code for the test method is this:
Code:
0:getstatic#18; //Field one:Ljava/lang/Object;
3:ifnonnull15
6:getstatic#20; //Field two:Ljava/lang/Object;
9:ifnonnull15
12:invokestatic#22; //Method func:()V
15:getstatic#18; //Field one:Ljava/lang/Object;
18:ifnonnull30
21:getstatic#20; //Field two:Ljava/lang/Object;
24:ifnonnull30
27:invokestatic#22; //Method func:()V
30:return
As you can see the generated code for both code variations are identical.
kind regards,
Jos
> That's true, but the same is true of nested if statements.I was arguing (though I did spell it out explicitly) that both variants are conceptually equivalent, and you can hence assume they do not differ in runtime efficiency.
As a beginner of programing world I want to know something. Is it necessary to know about Java bytecode in detail to be a good java programmar? and if yes is it too hard to master?
> As a beginner of programing world I want to know something. Is it
> necessary to know about Java bytecode in detail to be a good java
> programmar? and if yes is it too hard to master?
It isn't really needed to know the bytecodes generated by a compiler
although sometimes it helps a bit: I used it in reply #4 to settle the
argument: at least for the compiler embedded in Eclipse identical
code is generated for a nested if-if and the && operator and I'm about
sure that javac (Sun's java compiler) does the same.
btw, you can disassemble a class with the 'javap' tool which comes with
the JDK distribution.
kind regards,
Jos
"premature optimization is the root of all evil" - Donald Knuth
What he was trying to say is that it's much more important for code to be correct than it is for it to be fast. Another one about optimization, is M.A. Jackson's rule:
1. Don't do it.
2. (for experts only) Don't do it yet - that is until you have a perfectly clear, unoptimized solution.
> 1. Don't do it.
> 2. (for experts only) Don't do it yet - that is
> until you have a perfectly clear, unoptimized
> solution.
It's a good advice and I agree if we are talking about micro optimizations. I don't agree if we are talking about design. Trying to change a bad design (which can cause bad performance) is usually hard when the application is completed.
Kaj
Thank you all very much; you answered my question and then some. I guess optimization is a C++ obsession I have been affected with:)
To paulcw: I knew the performance gain would have to be minute if any, however if the code where to be in a loop executing say a million times (and yes I have written code where this was the case), the difference may have been noticeable. Thank you anyway for sparking the debate:)
> > 1. Don't do it.
> > 2. (for experts only) Don't do it yet - that is
> > until you have a perfectly clear, unoptimized
> > solution.
>
> It's a good advice and I agree if we are talking
> about micro optimizations. I don't agree if we are
> talking about design. Trying to change a bad design
> (which can cause bad performance) is usually hard
> when the application is completed.
>
> Kaj
That's certainly true. I've seen applications that were so terribly slow by design they were next to useless.
The designers had not had any thought for the performance of their systems, only for the theoretical correctness (making the class diagrams look nice, incorporating as many design patterns as they could, as many abstraction layers as inhumanly possible, etc).
End result: a single roundtrip to the database would require the passing of about a dozen application layer boundaries, each accompanied by multiple factory calls to create the objects needed to 1) pass the boundary and 2) create the objects needed to work on the other side of the boundary.
It was on paper a brilliant design. So loosely coupled you could fly a 747 through the holes without hitting anything.
But the price in performance was such that generating form letters from the database would take 5 minutes per page.
> To paulcw: I knew the performance gain would have to
> be minute if any, however if the code where to be in
> a loop executing say a million times (and yes I have
> written code where this was the case), the difference
> may have been noticeable.
Only if what you were doing inside the loop was comparable in execution time to the difference between the two cases. Otherwise, the loop's work will dwarf any difference in the if part into insignificant.
> as you can see the generated code for both code> variations are identical.And this tells you what? That's right, nothing. Some other compiler may do something totally different.
> > as you can see the generated code for both code
> > variations are identical.
>
> And this tells you what? That's right, nothing.
Not exactly.
It's a common construct, and if a couple of the most commonly used java compilers do the same thing, then it's highly probable that you'll never see any difference. No guarantees of course, but we are allowed to use common sense to make and act on reasonable inferences from time to time.
jverda at 2007-7-21 17:39:38 >
> "premature optimization is the root of all evil" -
> Donald Knuth
>
> What he was trying to say is that it's much more
> important for code to be correct than it is for it to
> be fast. Another one about optimization, is M.A.
> Jackson's rule:
>
> 1. Don't do it.
> 2. (for experts only) Don't do it yet - that is
> until you have a perfectly clear, unoptimized
> solution.
No, not again.
First, this is a discussion about a performance issue. Which is better X or Y. It's paramount to discuss such matters without any concern about a potential misuse of the outcome.
Second, having a number of functionally equivalent options, why not use the most efficient one? Is it better to use the least efficient one out of ignorance?
Third, this discussion isn't about optimization. An optimization takes place when you lower the level of abstraction to gain efficiency. This is not the case here.
jverda at 2007-7-21 17:39:38 >
> I have a question concerning the speed of my java
> code. Since this is my first post on this forum I
> hope you all can forgive me if a should have posted
> this question somewhere else on this forum.
A person who is polite - uses code tags - and even asks if it's in the right forum ? Surely you lie about this being your first post, as even those who have had dozens of posts can't figure out these simple ideas.
(It was meant as a compliment - keep up the good work ;-P )
> > And this tells you what? That's right, nothing.
>
> Not exactly.
>
> It's a common construct, and if a couple of the most
> commonly used java compilers do the same thing, then
> it's highly probable that you'll never see any
> difference. No guarantees of course, but we are
> allowed to use common sense to make and act on
> reasonable inferences from time to time.
I argued against the idea that a bytecode listing proves something about Java in general. It doesn't.
Still it prompted you to explain what conclussions can be drawn from such a listing in this case which is good because it isn't obvious at all.
> First, this is a discussion about a performance
> issue. Which is better X or Y. It's paramount to
> discuss such matters without any concern about a
> potential misuse of the outcome.
Uh, no. The question may have been which is more efficient, but that doesn't mean we can't discuss related issues, in particular the fact that there are other forms of efficiency than just speed, and that premature optimization can lead to bad code.
Once again, you're trying to censor based on your strange dogma.
> Second, having a number of functionally equivalent
> options, why not use the most efficient one? Is it
> better to use the least efficient one out of
> ignorance?
No, but it's better to use the one that most clearly expresses the intent of the code.
> Third, this discussion isn't about optimization. An
> optimization takes place when you lower the level of
> abstraction to gain efficiency. This is not the case
> here.
Eh? It's exactly the case here. The OP was asking which was more efficienct -- trying to gain efficiency -- without respect to which was the most clear.That's a reduction in abstraction. You're just expressing it differently (although nicely).
Anyway -- your objections have been noted: We have transgressed one of the doctrines in UJ's Big Book of Dogma. Thank you.
