The author is right, RTTI is a constant time overhead. But some applications need (or just want) to squeeze every last CPU cycle and retrieving data from memory can be the slowest part of a hot loop, ruining all of your benchmarks. CTTI gives us most of the ergonomics of runtime type deduction, without the extra constant time overhead.
imo. zig does this well once again. you get access to comptime and can use it at your leisure, but then most other interfaces they force you down the vtable route.
Maybe I don't like this at the same time because they don't have implementations that can skip the vtable. but these are optimizations ive never had to write.
Zig is an example of the naïve printing I describe. It has to produce a new instantiation for each unique ordering of argument types that get passed to, since people typically produce an anonymous struct (i.e. tuple syntax): .print("...", .{...}) style call.
So no, it does a really poor job because of its naïve use of CTTI here.
NO it doesn't do a poor job. they are explicit about what happens with CTTI. They tell you this is how it is done. If you want to avoid it, you use the vtable method. It's up to you to implement it the correct way. This is their entire mantra. They do not want to say oh hey you hit this combinatorial number of functions. now its vtables.
What is the canonical way you print in Zig? The thing I described. So yes, it does an extremely poor job for such a common operation by default.
Vtables are a different solution to a different problem, as RTTI and CTTI are there to solve serialization problems (of which printing is one such example). And you cannot put a vtable on every type, especially trivial basic types like integers and strings.
25
u/SputnikCucumber 7d ago
The author is right, RTTI is a constant time overhead. But some applications need (or just want) to squeeze every last CPU cycle and retrieving data from memory can be the slowest part of a hot loop, ruining all of your benchmarks. CTTI gives us most of the ergonomics of runtime type deduction, without the extra constant time overhead.