large enums slow down compilation #9081
Comments
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Aug 12, 2024
This commit improves the compile time of generating bindings for enums with many cases in them (e.g. 1000+). This is done by optimizing for enums specifically rather than handling them generically like other variants which can reduce the amount of code going into rustc to O(1) instead of O(N) with the number of cases. This in turn can greatly reduce compile time. The tradeoff made in this commit is that enums are now required to have `#[repr(...)]` annotations along with no Rust-level discriminants specified. This enables the use of a `transmute` to lift a discriminant into Rust with a simple bounds check. Previously this was one large `match` statement. Closes bytecodealliance#9081
|
I've tested that with #9122 the enum in question goes from generating 80_000 lines of code to 8_000 lines of code, which should be a large improvement. When that lands though can you confirm that it improves things locally as well? If the compile time is still too long I'll look into this further and see what else is generating a lot of code. |
|
@alexcrichton I would be happy to test it! |
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 12, 2024
* Improve codegen for enums with many cases This commit improves the compile time of generating bindings for enums with many cases in them (e.g. 1000+). This is done by optimizing for enums specifically rather than handling them generically like other variants which can reduce the amount of code going into rustc to O(1) instead of O(N) with the number of cases. This in turn can greatly reduce compile time. The tradeoff made in this commit is that enums are now required to have `#[repr(...)]` annotations along with no Rust-level discriminants specified. This enables the use of a `transmute` to lift a discriminant into Rust with a simple bounds check. Previously this was one large `match` statement. Closes #9081 * Fix some tests * Add repr tag in fuzzing * Fix syntax for Rust 1.78
|
@alexcrichton tested the changes and they definitely solved my issue! thanks a lot! |
|
Great, thanks for testing! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Related to bytecodealliance/wit-bindgen#1019
I have a large enum with 1424 cases. While it's completely broken on the client side, it works as expected on the host side, but compilation takes ages. On this Macbook Pro M3 Pro it takes 1 minute longer on a fresh compile than without the enum.
I attached the wit for testing.
icons.wit.txt
The text was updated successfully, but these errors were encountered: