To my naive understanding, it sounds like instanceof involves a simple iterative search through the objects parent types.No doubt some kind of caching mechanism might be employed to reduce the cost of this operation to a high O(1), rather than a low O(n).

I've never noticed instanceof as being a performance problem. I usually try to avoid it, but there are situations, where doing it in another way isn't appropriate. Replacing it by getType()==<YOUR_CONSTANT> is the poor man's solution to get rid of it. I did that myself in the past but i'm not doing it anymore. If i'm too lazy to do it right, i'm simply using instanceof now instead of using that half-baked-pseudo-OO-getType()-solution.

But if you read the thread referenced above, also notice that Cas offered the correct solution without instanceof or getObjectType() kind of uglyness. TBH, I can't think of a situation where instanceof is the appropriate way?

But if you read the thread referenced above, also notice that Cas offered the correct solution without instanceof or getObjectType() kind of uglyness. TBH, I can't think of a situation where instanceof is the appropriate way?

Do you remember when we were trying to squeeze out the last drip of performance out of Jemu2?

So while the 'visitor pattern' hinted by princec is very neat, the JIT turns it into a big jump-table anyway, which probably has similar performance as the dirty way. Going OO certainly won't make it faster.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I used instanceof a lot in the past in conjunction with "tagging interfaces", but nowadays annotations are used for this, though. But I still can think of many different scenarios where I don't want to clutter my API with a visitor pattern, just to do something in an OO way, when I could centralize control flow with a bunch of if/then statements. To follow the example with the Fruits and the Eater from the linked thread: with common sense, I would never apply a visitor pattern here. In a real world, an Eater would try to identify what is on the plate and then decides what action to take to get the served thing eaten. Regardless of good OO principles

TBH I think the "instanceof==bad" attitude is artificial and using instanceof has practically no downside, if not overused.

Replacing it by getType()==<YOUR_CONSTANT> is the poor man's solution to get rid of it. I did that myself in the past but i'm not doing it anymore. If i'm too lazy to do it right, i'm simply using instanceof now instead of using that half-baked-pseudo-OO-getType()-solution.

Actually I think the getType() approach is worse than instanceof. We just tried to squeeze a better performance out of the scenegraph analysis, but this can be considered a failure, so there is even less reason to consider getType() as a solution for anything... either use a visitor pattern or instanceof.

It was, but somehow isn't anymore. The M68k emulator now doesn't use switch-tables anymore because nowadays that's the faster way afaik.Don't know exactly which version of the JRE changed that, but it's something later than 1.4.

Quote

So while the 'visitor pattern' hinted by princec is very neat, the JIT turns it into a big jump-table anyway, which probably has similar performance as the dirty way. Going OO certainly won't make it faster.

Before the coming of NIO, there was a non-blocking networking architecture someone developed with a bit of JNI. I'm beating myself up trying to remember the name of it and Google isn't helping me. It certainly wasn't an obscure project. Anyway, I remember it was a very performant bit of code. The native part was minimal and most of the work, dispatching Network events and such, was handled on the Java side. I was shocked when I first looked at the source and saw that the dispatcher used instanceof to route the events. My naive assumption had been that instanceof would have been a bottleneck for something like that. From then on I wasn't afraid to use it.

instanceof is as fast as you could possibly get for a plugin architecture when you think about it - all the "workarounds" with getType() are probably just naive unoptimised versions of what the JVM is doing under the hood to implement instanceof. But probably without the clever cacheing.

Brain exercise: imagine you're making a plugin architecture for somesuch thing and you want to implement what amounts to a visitor pattern but at the class level. What might that look like? (Invent new syntax if necessary)

Wow, I ran some tests, and instanceof really is lightning fast.I made new Test[10000000] containing 50% Test1 and 50% Test2 objects, then iterated over all of them, calling getValue() on each. This took about 1350 ms.I made another loop, doing instanceof on each object, testing against both Test1 and Test2, setting the value to what the object call would return. This ran in about 700 msOut of curiosity, I also made a loop that did getType() and compared it against a static final int (basically a manual version of instanceof), and this ran in 1350 ms.

instanceof is still bad, imo, as in order to add new code, you have to find all the places you use instanceof and insert code there, instead of having it all encapsulated in one place.. but if you have a tight inner loop that you want to get rid of a costly method call in, instanceof actually seems like a good idea, as it's almost twice as fast (in my very naive test).

For example, I'm working on a simple game where you're a character that runs through a maze and fights monsters and bosses and gets items. Every Room in the maze has a single Entity, which can be null. If an Entity is trying to move and has another Entity in its way, it will only attack the other Entity if its an enemy. There are two extensions of Entity: PlayerEntity and EnemyEntity. Each only wants to attack in the case where (enemy instanceof EnemyEntity) or vise versa.

Because my bottleneck is most certainly in my pathfinding algorithm (A* in a maze), I don't even begin to care about instanceof. It works. Later I might give each Entity a faction or something, and then allow more than just two "teams," but the way it is now, instanceof is fast and works great.

Can you run your test with a more hierarchical approach? For instance, Test1 extends Test2 which extends Test3 or Test4 etc. The "homemade" versions shouldnt see a huge performance hit from this, but I wonder if instanceof does. Interesting nevertheless though!

Can you run your test with a more hierarchical approach? For instance, Test1 extends Test2 which extends Test3 or Test4 etc. The "homemade" versions shouldnt see a huge performance hit from this, but I wonder if instanceof does. Interesting nevertheless though!

Surely you're getting into an apples<->oranges comparison there? instanceof means it's castable to that type, numeric ids just establish that it's an exact match. A more appropriate comparison would be replacing instanceof with .getClass() == Type.class surely? (which I'd expect to perform the same as the numeric id approach - they're both going to be an accessor and a comparison).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org