views:

173

answers:

5

So say for example I'm going through an 'if' block and in this block, I am comparing the value of some number to a constant. Would it be more expensive like this:

if( foo.getOb().getVal() == CONST_0 )
{
     ....
}
....
if( foo.getOb().getVal() == _CONST_N )
{
     ....
}
else
     ....

OR:

int x = foo.getOb().getVal();
if( x == CONST_0 )
{
     ....
}
....
if( x == _CONST_N )
{
    ....
}
else
    ....

I know that this may seem like a stupid question. I think that the second implementation is fast/more efficient but I'm curious as to why. I've been trying to think of the reason for the last couple of minutes and can't really come up with anything since my knowledge on Java is...a bit lacking.

Thanks a lot for any answers!

+5  A: 

This is not object creation. You are creating a reference to the object.

You are saving a few method-calls (in Java they are very efficient)

The difference is negligible. And It is not unlikely that the compiler will optimize such things.

Bozho
His `val` is `int`. So `==` is the only option.
Alexander Pogrebnyak
a, yes, fixing.
Bozho
No `x` won't have to be garbage collected. It is a primitive type allocated on the stack.
Justin
Even if it wasn't a primitive type, `x` is just a reference to the object from `getVal()`, it's not an extra instance of the object
matt b
Correct. removed that part (I myself said it isn't a new object.. :) )
Bozho
+3  A: 

Assuming getOb() and getVal() simply return references and don't do calculations, then these two snippets of code are functionally equivalent. Meaning that there is no real discernible difference between them.

Debating between which form to use comes down to a question of style and preference, and borders on pre-emptive optimization (in that you may spend a lot of time arguing about making a change which has zero measurable impact on your application's performance).

matt b
+2  A: 

It really depends on how getObj() and getVal() are implemented. If they are expensive operations, then yes, your second example will almost always be faster. However, if you are concerned about the overhead of just the method call, don't be. The JIT compiler often can often times inline method calls, and even if it doesn't, there is very little overhead. Similiarly with the allocation on the heap for the local variable, these operations are very fast, and unless you've identified a performance "hotspot" through profiling, it's too early to start thinking of what's going to perform faster.

See here for more on premature optimization: http://stackoverflow.com/questions/385506/when-is-optimisation-premature.

As a rule, write your code so it's easy to understand and correct first. And only if you've identified a clear bottleneck should you start trying to optimize for speed/memory. You will save yourself, and your colleagues that are trying to maintain/debug your code, time and frustration by writing for code clarity first.

gregcase
+2  A: 

The example code violates the Law of Demeter. It should be

if( foo.isConst0() )
{
    ....
}

anyway. Also, premature optimization is the root of all evil

mhaller
So, to be clear, you suggest that he implement foo.isConst0(), foo.isConst1(), foo.isConst2()..., foo.isConstN() ?Seems super ugly, and I'm pretty sure just having foo.getObjVal(), and then checking against the values is well within the constraints of the "Law" of Demeter.
biggusjimmus
Asking an object for its internal state violates OO. There should be meaningful names, e.g. foo.isInStateBar() and alike. Abstract examples don't help much here. Better to see with real, meaningful names. foo.isInStateBar() better than foo.getObj().getVal()==3
mhaller
+7  A: 

It looks to me that you should be using a switch statement, in which case, you don't need to worry about it.

switch (foo.getOb().getVal()) {
    case CONST_0:
        .... 
        break;
    case CONST_N:
        .... 
        break;
    default:
        .... 
        break;
}
Peter Lawrey