Does casting to interface better than casting to actor in performance as some of YouTube content creators say ?
Because what I know about interfaces that they r used when a class has a function that multiple object have their own implementation for this function for example.
If you want to cast to an actor, you have to #include its class into the one doing the casting. If you’re working with various different classes, you can include either all of those classes, or just a few light interfaces that only have several function declarations.
And the casting itself, I guess it has to allocate some memory to the pointer, and the larger the class, the more it needs?? I’m not sure about this one though, I don’t know how it really works =)
1 Like
i know ur first point, i am asking about the second point.
imagine i want to get a bool from my character object so in utube they create an interface that returns that bool and cast to that interface instead of casting to the who character object as they r saying that is faster and save memory. but in OOB interface is not used for this approach i think, so i want to know before i cast to my character in many class if casting to interface better.
You don’t use interfaces for performance reasons. Interface functions are virtual and cannot be inlined, so if anything, there is a performance cost. However, programming at a gameplay level means that the penalty is practically always of no concern.
Interfaces are used for decoupling. The caller does not need to know anything about the class implementing the interface. This can save memory (because the caller only needs to know about the interface and not every class it could possibly call) or at the very least let you avoid undesireable inheritance hierarchies.
1 Like
so to make sure that i understood u, u suggest to cast to interface to save memory.
for example if i want to get character’s current health, i should implement a function called gethealth() in an interface class (CharacterInterface) and then cast to this interface to get the health only and by this way i will safe memory because i did not get a reference for the whole character object ?
Note: if it saves memory then the game is more optimized then how it does not effect performance ?
Think of something more generic, like an interface for interactions. Not every interactable object is necessarily going to be on every map at once, so you don’t need to add them to the memory.
If the character is going to be on the map anyway and that is the only class that has the interface you aren’t saving any memory. A pointer/reference is a memory address.
3 Likes
so if i am casting to the character in another class every tick to get only the character speed, i do not need to create a getspeed funtion inside interaction interface class to avoid hard reference and save memory ?
The character is probably a bad example since if it is already loaded it will not need to be loaded again.
I think you are missing the big picture of all this. performance tricks like interfaces and whatnot are important for repetitive, time consuming tasks. then is my understanding that one needs to implement C++ code, optimized and the rest.
So if you are checking the health on your player once a frame is like a drop a in a huge bucket of available computer power. Checking the life on 10000 Ai actors may probably be an issue and you need some custom high level stuff. maybe. Or maybe the engine is optimized to do this anyway.
What I found useful for the interfaces is that I can reuse the code if for example I change the name of the player class blueprint. now someone told me on this forum that I can cast to the base class. But I’m not sure I can then use the custom functions from the child class.
This is a mental trap I got tangled all the time. Starting to think about performance like I’m creating some sort of high level real world Formula 1 car that needs everything ultra-optimized, when in reality I’m building a wooden cart.
Yes it is easy to fall in the trap of thinking about performance before readability but in reality readability IS performance, since code is written by people and people tend to make mistakes especially when the readability is poor and mistakes often cost a lot of performance.
Speaking of hard references, if you avoid hard references it also makes refactoring quicker and the editor load faster etc. so decoupling has several benefits.
I think you are missing the big picture of all this. performance tricks like interfaces and whatnot are important for repetitive, time consuming tasks. then is my understanding that one needs to implement C++ code, optimized and the rest.
Interfaces aren’t performance tricks.
So if you are checking the health on your player once a frame is like a drop a in a huge bucket of available computer power. Checking the life on 10000 Ai actors may probably be an issue and you need some custom high level stuff. maybe. Or maybe the engine is optimized to do this anyway.
Checking health on tick is generally bad practice even from a non-performance standpoint.
What I found useful for the interfaces is that I can reuse the code if for example I change the name of the player class blueprint. now someone told me on this forum that I can cast to the base class. But I’m not sure I can then use the custom functions from the child class.
Interfaces in C++ and Unreal are implemented via multiple inheritance. You’re just adding another class to inherit from that doesn’t really have anything but function declarations.
Interfaces allow us to avoid those deep inheritance hierarchies which make the code monolithic and too hard to change after the fact. Inheritance in general is at it’s best when the inheritance trees aren’t deep.
This is a mental trap I got tangled all the time. Starting to think about performance like I’m creating some sort of high level real world Formula 1 car that needs everything ultra-optimized, when in reality I’m building a wooden cart.
Rather than performance it’s better to think what sections of code can be decoupled from the rest. That makes it easier to change later on when changes made don’t have large cascading side-effects.
4 Likes
i am thinking about performance at this small parts because i might have a future implementation that takes huge resources and it is hard for me to optimize it so i know it is stupid to think about performance over the implementation.
yea it is right sometimes i forgot what this code does because it is not readable because i focused on optimizing it over being readable.
so if a character inside the world and i casted to an actor of this character type it does not hard reference it ?
the problem is the documentation is not clear and does not have these important information, and sometimes reimplementing function before thinking about the best practice or a good practice at least, this will make u reimplement it and this is pain in the a** because u need to finish ur project at specific time.
thing is that I’m learning game dev for the past two years and there is so much to learn and I’m running out of time.
Because I’m trying to build a game by myself is not a good tactic to learn all these advanced tricks for each game dev area.
so my answer is who cares, if it works, for now is good enough.
if you are working on a team and your role is to think about how to write good code and that is about all you do then you are correct, you need to know all this stuff.
but for me, trying to understand how optimize something beyond basic level is impossible if i also want to release a game.
Because I need to optimize code, textures, meshes, animations, blueprints, physics, network and on and on.
Maybe with time one understands all this but for now if I hit play and the game works fine by me.
So inheritance casting whatever from this point of view matter less.
I’m not trying to teach something to someone who knows what he is doing. I’m saying that from my point of view I don’t have time for all of this. I know this is important and I would love to understand C++ at advanced level but I will not have time for the rest of stuff that needs to be done 
1 Like
A cast is simply telling the compiler what kind of object the programmer THINKS the pointer is referencing. Anything else is dependent on how you use the cast variable.