Hacker News Reader

Comment by dminik | Hacker News Reader

A really dumb 1 AM question. If there is a lot of work thrown away because stuff is compiled even if not needed, would making every function generic and delaying compilation until instantiation help here?

Note that it's not a serious suggestion, but I wonder what effect it would have on build times.

View on HN

The downside of this is that if two crates use the same function each of them will have to codegen it, duplicating the work needed for those functions.

As always this could be avoided with some extra complexity, but that require lot of work and testing that hasn't been done.

So for now this is useful only in crates that have a lot of unused functions, so even if one function is codegenned multiple times you still save time overall.

Yes, and there is some compiler flag to do this, even though it's not 100% intended for this use (I think it's something like mir-inline-trheshold=0).

There's also -Zhint-mostly-unused flag.

The tradeoff is that these functions then have to be encoded in metadata for downstream crates, so it's not necessarily faster.

I mean, the core thing is like, you have to have a compiler codebase (and language semantics) that's designed around being able to delay in the first place to be able to even try this, and once you've gotten that in place, well, it's not really about this specific idea anymore.

Would this work better in a language where generics are vtable based by default and only monomorphized as a form of LTO? If you have a Zig style machine IR where function calls are a "fake instruction" you can decide between direct and virtual call at final codegen time.

That would mean generics in shared libraries are possible without hacks but you can always choose to statically link and monomorphize for speed. Libraries could even ship both the vtable based catch all code and specializations for common types as a fast path (but that would probably need a custom dynamic linker).

It really depends on a lot of things. This design is possible, yes, but it also means that you can't have some of the same features as Rust has. Rust's traits can be "non-dyn safe" (which used to be called "non-object safe"), because sometimes you cannot use them via a vtable, and must use them via monomorphization. So you can have languages that do things this way, but they make other tradeoffs (either performance ones or power ones, depending).

Reply on news.ycombinator.com