| > extracted via reflection 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. [0]: https://gdzig.github.io/gdzig/#gdzig.builtin.string_name.Str... [1]: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d... [2]: https://github.com/gdzig/gdzig/blob/5abe02aa046162d31ed5c52f... |
Thanks for the overview.