I think you are talking about dispatch of virtual methods, which is still a thing, but the performance cost can be somewhat mitigated.
the names of the methods are interned strings (called `StringName`). a naive implementation will allocate the `StringName`, but you can avoid the allocation with a static lifetime string. we expose a helper for comptime strings in Zig[0].
then, extension classes need to provide callback(s)[1] on registration that lookup and call the virtual methods. as far as I know, the lookup happens once, and the engine stores the function pointer, but I haven't confirmed this yet. it would be unfortunate if not.
at least right now in GDZig, though this might change, we use Zig comptime to generate a unique function pointer for every virtual function on a class[2]. this implementation was by the original `godot-zig` author (we are a fork). in theory we could inline the underlying function here with `@call(.always_inline)` and avoid an extra layer indirection, among other optimizations. it is an area I am still figuring out the best approach for
virtual methods are only ever necessary when interfacing with the editor, GDScript, or other extensions. don't pay the cost of a virtual method when you can just use a plain method call without the overhead.
They had to copy that bad idea from Unity, where methods are named in a specific way and then extracted via reflection.
Either provide specific interfaces that components have to implement, use attributes, or make use of generics with type constraints.
Maybe for Unity that made sense as they started with scripting languages, and then bolted on Mono on the side, but it never made sense to me.