4 ms·
Almost any "large anything" hits pathologic behavior in a compiler. For example, try to compile a Rust `match int { 0 => 0, ..., MAX => MAX }` statement with o
by fluffything 7y ago
Almost any "large anything" hits pathologic behavior in a compiler.
For example, try to compile a Rust `match int { 0 => 0, ..., MAX => MAX }` statement with one arm per `int` value: you'll notice that for `u8` this kind of works fast: 1 - 2 seconds on my machine, but that means I'd expect compilation to take ~4-8 minutes for a `u16` with `u16::MAX` match arms, yet it takes > 30 minutes [0].
So the complexity of compiling Rust match statements is not linear in the number of match arms. And this is with a single language feature in isolation.
Now write a 100k LOC function using many different language features, each of which have worst case complexities larger than O(N), with different constant factors.
[0]: it doesn't really matter that much to me why this is the case. E.g. the compiler might be building extra data-structures that fill in the RAM, and then my system starts swapping, and it crawls. Point being, the problem is too large for my system, but one is able to hit this problem on any system with a sufficiently large input.