The Performance Impact of Using Instanceof in Java

The performance impact of using instanceof in Java

Modern JVM/JIT compilers have removed the performance hit of most of the traditionally "slow" operations, including instanceof, exception handling, reflection, etc.

As Donald Knuth wrote, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." The performance of instanceof probably won't be an issue, so don't waste your time coming up with exotic workarounds until you're sure that's the problem.

Does instanceof operator generate a lot of overhead ? Why?

It does generate some overhead, combined with the subsequent casting. With recent version of Java the overhead has decreased. But anyway that's microoptimization - i.e. you should not worry about it in the general case.

The real argument against instanceof is that in many cases there are better OOP ways to achieve the desired behaviour.

Does using instanceof help and java cast type exception hits performance?

1. If you use instanceOf then you do not need try-catch(ClasscastException e). instanceOf is guaranteed to work, even with nulls.

2. In today's VMs, casting does not show any measurable performance hit. Rather if you find doing casting too often, then revisit your design.

NOTE: instanceof does not work with Generics due to type erasure.

Impact of 'instanceof' in Android Java code

I do not think instanceof bears a heavier impact on the Dalvik VM opposed to the JVM.

If you have any doubts, you can see for yourself when you run your application with a tool called Allocation Tracker that comes standard as a tool for the DDMS.

What's faster: instanceof or isInstance?

Class.isInstance is JVM intrinsic. It is compiled to exactly the same sequence as instanceof does (the proof from HotSpot source code: 1, 2). That is, they both are equal in terms of performance.

instanceof vs polymorphism - Why is instanceof faster?

The JVM only inlines up to 2 possible implementations from a call site. This means if you have more than 2, the code won't be as optimised for some cases.

If instead, you do your only if/else, there is likely to be just one implementation to call and thus it can all be inlined.

Inlining is a key feature of many optimisation techniques.

In short, if you have a megamorphic call you can see a small but significant improvements by refactoring it if the code is hot enough.
http://insightfullogic.com/2014/May/12/fast-and-megamorphic-what-influences-method-invoca/

Overhead of rethrowing Java exception vs. using instanceof/cast

As as matter of style, I generally recommend not using exception handlers for regular control flow. I can see the argument for using it here, though, as the design of Future requires you to 'unwrap' the original exception.

Rethrowing an exception should be substantially less expensive than throwing a new exception, as the stack trace has already been populated. There may still be more overhead with your first approach, but if your application is throwing so many exceptions that the impact becomes noticable, then you likely have bigger problems.

If it's really a concern for you, the only way you'll get a meaningful answer is to measure the difference yourself. But, again, exceptions should only be thrown in exceptional cases; they should be uncommon by design. Even if you double the cost of exception handling, the cost is merely 2n instead of n. If you're throwing so many exceptions that your application's performance is suffering noticeably, a simple factor of two probably isn't going to make or break you. So use whichever style you find more readable.

What is the difference between instanceof and Class.isAssignableFrom(...)?

When using instanceof, you need to know the class of B at compile time. When using isAssignableFrom() it can be dynamic and change during runtime.

---

Related Topics