I was looking at the answers of this question.
How can it be possible that instanceof has turned out faster than a polymorphic call like equals.
Asked
Active
Viewed 95 times
0
-
3You mean the long and detailed answer with the Gist code and graphs? Everything is possible in a botched microbenchmark, which that answer is an instance of. – Marko Topolnik Sep 28 '16 at 06:44
-
you already have your answer in the link you are just using equals instead of == rest same as linked question , explore the all answers in the link – Pavneet_Singh Sep 28 '16 at 06:45
-
@Marko Topolnik: no, that long and detailed answer does not make such a claim. I suppose, this question refers to the second most (undeservedly) upvoted question, which compares two entirely unrelated operations (string equality check and `instanceof` operator). – Holger Sep 28 '16 at 09:40
-
@Holger I believe we are both referring to [this answer](http://stackoverflow.com/a/26514984/1103872). It's the second-most upvoted one and the only one with graphs and Gist'ed code. But i don't see string equality there; i see `.class` compared with `==`, an `else-if` cascade with `instanceof` and a `switch` with `type`. It's broken in many ways. – Marko Topolnik Sep 28 '16 at 09:55
-
@Marko Topolnik: seems, I can’t count to three anymore. No, I assume, this question referes to [this answer](http://stackoverflow.com/a/397617/2711488) which indeed compares `instanceof` with `String.equals`… The other answer can also be considered questionable regarding its benchmark methodology, etc., but it makes more sense than comparing `instanceof` with `String.equals`… – Holger Sep 28 '16 at 10:09
-
@Holger Both the answer and the discussion below it is such total nonsense that explaining what is wrong with it would take longer than writing a new answer from scratch. – Marko Topolnik Sep 28 '16 at 10:13
-
@Marko Topolnik: most answers there are crap. What I like about the answer with the graphics is, that the bars look so random, that it’s even possible to draw the correct conclusion from it. Unfortunately, nobody did… – Holger Sep 28 '16 at 10:18
-
@Holger Given that the measurement loop _always_ involves a `switch` statement that decides what to instantiate, the results are truly meaningless. – Marko Topolnik Sep 28 '16 at 10:20
-
@Marko Topolnik: yeah, and the most expensive operation of every iteration is the use of the `Random`, which is also the only thing that can’t be optimized away, as it’s initialization advances a global `seedUniquifier`. – Holger Sep 28 '16 at 11:20
-
@Holger Yes, it's the old-school thread-safe, high-overhead `Random`. – Marko Topolnik Sep 28 '16 at 11:21
1 Answers
3
I suppose, you are referring to this answer which should be downvoted to the ground instead of getting so much upvotes. First of all, any numbers posted without showing the actual code under test nor naming any benchmarking tool should be considered to be a (perhaps) interesting comment rather than a quality answer.
Second, this answer compares two entirely unrelated operations, a String equality check and the instanceof operator. That answer misleads the reader (like you) into thinking that it bears any finding about the cost of Java’s method dispatch, but there is no way to measure that cost in isolation. If you measure the cost of invoking a method doing work X (like String comparison), you’re basically measuring the costs of work X (the String comparison), rather than the invocation cost. Since instanceof doesn’t perform a String comparison, it’s obvious that it does less work than calling String.equals. Especially, as the implementation of String.equals(Object) even does an instanceof on the argument.
So it should not surprise you when calling String.equals imposes more costs than doing a sole instanceof operation, giving an answer to an entirely different question. The linked answer still is not sufficient to prove that this actually did happen. Measuring 80±17ms and 168±62ms for a loop of 10,000,000 iterations is a clear sign that the actual costs of the loop body are buried deep under statistical noise.
Besides all that, String.equals can not even considered a polymorphic call.
