views:

282

answers:

4

Would there be any performance differences between these two chunks?

public void doSomething(Supertype input)
{
    Subtype foo = (Subtype)input;
    foo.methodA();
    foo.methodB();
}

vs.

public void doSomething(Supertype input)
{
    ((Subtype)input).methodA();
    ((Subtype)input).methodB();
}

Any other considerations or recommendations between these two?

A: 

Acording to this article, there is a cost associated with casting: http://www.javaworld.com/javaworld/jw-12-1999/jw-12-performance.html

Oso
Do you think there's a slight possibility that Java performance considerations may have changed in the last 10 years? :)
Jon Skeet
+6  A: 

Well, the compiled code probably includes the cast twice in the second case - so in theory it's doing the same work twice. However, it's very possible that a smart JIT will work out that you're doing the same cast on the same value, so it can cache the result. But it is having to do work at least once - after all, it needs to make a decision as to whether to allow the cast to succeed, or throw an exception.

As ever, you should test and profile your code if you care about the performance - but I'd personally use the first form anyway, just because it looks more readable to me.

Jon Skeet
I often use the second type if I am only doing one thing with the cast object. This is a simplification of a situation where several times in the method I do 'just one thing'. Effectively wondering if it's worthwhile to declare a cast reference at the beginning of the method to use throughout. (Though admittedly that's a slightly different question.)
Ipsquiggle
@Ipsquiggle, there is no cost of declaring the cast reference beforehand. The compiler needs to create that reference anyways, even though it is a sort of "anonymous reference".
Yoni
Accepting this answer because it has more votes, though this one and Jonathan M Davis' answer are nearly identical.
Ipsquiggle
+2  A: 

Yes. Checks must be done with each cast along with the actual mechanism of casting, so casting multiple times will cost more than casting once. However, that's the type of thing that the compiler would likely optimize away. It can clearly see that input hasn't changed its type since the last cast and should be able to avoid multiple casts - or at least avoid some of the casting checks.

In any case, if you're really that worried about efficiency, I'd wonder whether Java is the language that you should be using.

Personally, I'd say to use the first one. Not only is it more readable, but it makes it easier to change the type later. You'll only have to change it in one place instead of every time that you call a function on that variable.

Jonathan M Davis
It's not a big worry, just one of those nagging doubts I'd like to clear up.
Ipsquiggle
@lpsquiggle That's understandable. All else being equal, it's good to code the way that's more efficient. Maintainability would likely be a bigger concern here though. But then again, the most maintainable one is also the most efficient one here, so it's a win-win.
Jonathan M Davis
A: 

In the first case :

Subtype foo = (Subtype)input;

it is determined at compile time, so no cost at runtime.

In the second case :

((Subtype)input).methodA();

it is determined at run time because compiler will not know. The jvm has to check if it can converted to a reference of Subtype and if not throw ClassCastException etc. So there will be some cost.

fastcodejava