Comment by fingerlocks
21 hours ago
The swift compiler is definitely bottle necked by type checking. For example, as a language requirement, generic types are left more or less in-tact after compilation. They are type checked independent of what is happening. This is unlike C++ templates which are effectively copy-pasting the resolved type with the generic for every occurrence of type resolution.
This has tradeoffs: increased ABI stability at the cost of longer compile times.
> This has tradeoffs: increased ABI stability at the cost of longer compile times.
Nah. Slow type checking in Swift is primarily caused by the fact that functions and operators can be overloaded on type.
Separately-compiled generics don't introduce any algorithmic complexity and are actually good for compile time, because you don't have to re-type check every template expansion more than once.
Separate compilation also enables easy parallelization of type checking.
You’re absolutely right. I realized this later but it was too late to edit the post.
A lot can be done by the programmer to mitigate slow builds in Swift. Breaking up long expressions into smaller ones and using explicit types where type inference is expensive for example.
I’d like to see tooling for this to pinpoint bottlenecks - it’s not always obvious what’s making builds slow.
>I’d like to see tooling for this to pinpoint bottlenecks - it’s not always obvious what’s making builds slow.
I second this enthusiastically.
I'll third it. I've started to see more and more cargo culting of "fixes" that I'm extremely suspicious do nothing aside from making the code bulkier.
> Breaking up long expressions into smaller ones
If it improves compile time, that sounds like a bug in the compiler or the design of the language itself.
>This is unlike C++ templates which are effectively copy-pasting the resolved type with the generic for every occurrence of type resolution.
Even this can lead to unworkable compile times, to the point that code is rewritten.