Are abstract classes faster than Interfaces in Java?

Question

According to this article here, on abstract class vs interface, abstract classes are SLIGHTLY faster than interfaces. Why is that and can you explain the mechanics of using interface vs abstract classes in terms of JVM ?

4. The fourth difference between abstract class and interface in Java is that abstract class are slightly faster than interface because interface involves a search before calling any overridden method in Java. This is not a significant difference in most of the cases but if you are writing a time critical application then you may not want to leave any stone unturned.

Answer 1

The answer is depending on implementation details, but in this form, it is not correct. In fact, the author does already try to dodge a fact-check by using the word “slightly” to be open to the possibility that you never observe such a performance difference.

As elaborated in this board, the idea behind such statement is, that an ordinary class has a table of overridable methods (also known as “vtable”) which is inherited by subclasses, which may add new methods at the end and replace table entries for methods they override. Hence, the first resolution only needs to find the table index, which can be remembered, so subsequent calls only need to invoke the method of the actual receiver class at that index.

Since interfaces may be implemented by different classes not having an inheritance relationship, the implementing methods may be at different table indices for these classes. One way to solve this, is to have some kind of mapping from the interface’s table to the actual class’ table. Assuming such kind of double-dispatch leads to the assumption that invoking interface methods was slower than ordinary methods.

However, JVMs like the HotSpot JVM do not use such double-dispatch. They resolve interface method invocations against the actual receiver class like any other virtual method invocation. As long as the receiver is part of the same class hierarchy, say, you invoke a method on the Appendable interface and the receiver is always a subclass of the Writer class, no additional steps are needed. For the majority of all interface method invocations, this works fairly well.

There are cases where the interface method invocation will end up at different implementations of unrelated classes, say, when an invocation of a method of Appendable sometimes ends up at StringBuilder and other times at Writer, but then, we have an incomparable scenario. This particular invocation may be slightly slower than an ordinary method invocation, but since it is impossible to construct the same scenario with an abstract class, it does not make any sense to say that it was slower than using an abstract class here.

For performance relevant code parts, also known as hot spots, the JVM will perform runtime optimizations which render such technical difference irrelevant anyway. Even the tiny overhead of an ordinary virtual method invocation will usually get eliminated, as the subsequent optimizations heavily rely on the ability to aggressively inline the code of the target method, to be able to use the caller’s context and its known surrounding conditions to optimize the callee’s code.

Answer 2

• Interfaces are Slow compared to Abstract classes because in resolving function calls made to an interface instance , JVM requires to lookup in virtual tables to know exact method of implementation class. This lookup takes time which is not needed for resolving abstract class method executions.
• So Abstract classes method call execution are faster than interface method executions.
• Modern JVM's are discovering ways to reduce this speed penalty when using interfaces.