Casting vs Class Equal To

[KristofMorva (Kristóf Morva)]

@originalbadboy

As I said cross purposes … I guess I meant for an object of an already know type (sorry should have clarified that bit). I should have stated that you don’t have to cast in general to an already known object type.

So getting back on topic, yeah lets just say that you just want to know a type of object, you might not want to do anything with it necessarily, just simply to know what type of object you are talking about. In a pure simple form it seems to me like Equal To is the faster option in that case. Obviously if you want to do something with that object afterwards you would still be casting to it, so in that case just casting would be more efficient.

It does seem from some of the responses though that Casting has it overheads, hence the question.

Yeah, just stick to an Equal Check. It has another positive side: you can also compare it with a soft class, which won’t hold a hard reference, so that you might have a smaller footprint for your class (both Cast and a Hard Class Reference equality check will involve a hard reference).

[BrUnO_XaVIeR]

@KristofMorva

If the cast is most usually successful here, won’t it be even slower? I’m pretty sure the Cast node itself also checks for failures (so that the failure check is done 2 times), and you also have an extra VM call (which is also expensive), and then we didn’t even talk about the extra complexity it adds to the graph.

It might still be useful in situations, but as far as I can see, it’s a bit of an overkill.

No, that node doesn’t cast anything.
It checks class inheritance under a limited scope of classes. Casting has no scope and it always casts an object returning either a valid or null pointer.

That node always return uncasted object, no pointer math.

[TheFlow3k]

Sorry to bump up such an old but interesting discussion. I am at the same point and unsure if I should use “cast” or “get class and check equal”.
I do not need the cast, but cast is only one node. As someone said already, “get class and check equal” needs three nodes. But what is better? What is fast?

I think “cast” do a hard reference and when you compile the actor with the hard reference the actor which references to are compiled also. Is that true or a misunderstanding? Do this also happen on “get class and check equal” instead using cast?
No technical UE4 Evangelist here running around to solve such a interesting question? , “get class and check equal” vs “cast to class”

[Wontague]

USE GetClass()->CheckEqual()

If you can, use the above, rather than Cast, especially on a BP graph.

GetClass() returns a pointer (4 bytes) to a UClass, and CheckEqual() will get the other UClass pointer, compare equality, and return a bool (1 byte). It’s incredibly cheap - like getting and comparing 2 floats. It runs only a few lines of code, from files that are likely already in memory - GameplayStatics & KimetMathLibrary & UObjectBase.

The BP Cast node creates an object - all member variables have to be initialized, all hard references need to be loaded, etc. This is almost certainly more expensive for memory, and I expect it’s more expensive on processing, even with the cost of 3 nodes versus 1, and especially so if using Blueprint Nativization.

Casting primitives (float to int, int to bool, etc.) in C++ is cheap. Casting to an object, though, requires trying to construct that object, so how cheap it is may depend on the objects involved.

BTW, the script we see when copying and pasting a node into Notepad is not relevant for memory or processing - this script does have the name of the Engine function being called (useful to know), but otherwise, I don’t believe it’s related to runtime. These scripts are mostly for the Editor to know how to display the nodes in the graph. It’s like the “Collapse Nodes” option - for human readability, without a runtime effect.

Also from above - to kill a hard references on the graph - use node “Set By-Ref Var” with Target == reference to kill, Value == None. The GC will see a reference to nullptr and dump it. Read about this on a blog, did a quick test, and it seems to work.

Another way to prevent storing the hard object reference of a cast, I imagine, is to cast within a function, so that after it runs, it’ll be destroyed. From the conversation above, though, it sounds like all references are loaded on BP construction, and I don’t know (and can’t easily test) if this keeps references within functions alive.

Would be interested to hear more.