cast removal

Performance Tuning
#1

Let’s say that i have a method that does like clone(), but implements the cloning itself. That method does not return an Object instance, but an instance of the class itself. I think it it to remove the need to cast, for two reasons: speed and typing reduced.
I don’t believe that doing so is clever, as duplicating processes for a task is a Bad Thing©, and can introduce bugs directly and during updates, but this is an other story.
My question at the moment is:
is the cast point valid? Wouldn’t hotspot remove the cast when returning from clone() in a case as the one below?

MyClass mc = (MyClass)myOtherClass.clone();

By the way… anyone ever benchmarked clone() opposed to hand done cloning?

#2

is there something wrong with the question, or simply nobody knows?

#3

Maybe no-one knows. It’s one of those things that’s not likely to be a performance bottleneck anywhere I shouldn’t think, either. I think that the cast is probably removable after the clone has been inlined.

Cas :slight_smile:

#4

I don’t think you even need the cast do you?

If MyOtherClass is derived from MyClass, then you should always be able to assign it to a base-class reference - at least you can in C++.

Casting the other way doen the inheritance tree is a different matter, and requires a cast and some care.

Speed wise I’m fairly certain that the cast would be more a compiler issue as opposed to generating any bytecodes from it - though I could be wrong on that too! :wink:

  • Dom
#5

Unfortunately clone() returns Object tho, so the cast is required.

Kev