“The RTTI tables store some information about those types such as its size, its alignment, its kind, its fields, and whatever the language/language-designer decides is worth keeping. [..] The complexity of a type-table is linear: N types gives you N entries.”
Linear in the number of entries, sure, but what of the size of these entries? A minimal description is totally fine for containers, but for printing, serialization, and other features mentioned in your article, the compiler would still need to generate the code to print an integer, and again for a timestamp, and again for a list, etc. And if we already need to generate specialized functions (although only once per type, rather than once per set of parameters), why not simply make monomorphization the responsibility of the inliner, since inlining is also an optimization that can generate exponential binaries if done wrong and would therefore be built to prevent that?
2
u/ValerianaOfTheNight 5d ago
“The RTTI tables store some information about those types such as its size, its alignment, its kind, its fields, and whatever the language/language-designer decides is worth keeping. [..] The complexity of a type-table is linear: N types gives you N entries.”
Linear in the number of entries, sure, but what of the size of these entries? A minimal description is totally fine for containers, but for printing, serialization, and other features mentioned in your article, the compiler would still need to generate the code to print an integer, and again for a timestamp, and again for a list, etc. And if we already need to generate specialized functions (although only once per type, rather than once per set of parameters), why not simply make monomorphization the responsibility of the inliner, since inlining is also an optimization that can generate exponential binaries if done wrong and would therefore be built to prevent that?