Long compilation time #29
Comments
|
That's surprising, are you sure it's this crate that's the bottleneck and not a different one? Cargo builds things in parallel and it's hard to tell from the output what the currently building crates are. Nightly has better output for this. I'm unable to reproduce any slowness with a quick test. |
|
Well, for example when I type in |
|
Oh, wait, no, was compiling the wrong thing. Yeah this contains some giant match statements which are slow. We could perhaps use something like phf_map here but that may not improve compile times. |
|
Okay, so as there is nothing you can do here, I'll just close it? |
|
It's worth filing an issue on the rust repo for this. There is stuff we can try here, though |
Speed up item_bodies for large match statements involving regions These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead. The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though). Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them. Ref #55528 cc unicode-rs/unicode-normalization#29 r? @nikomatsakis
Avoid layout calculations in assert_bits to speed up match checking assert_bits ensures that the given type matches the type of the constant value, and additionally performs a query for the layout of the given type to get its size. This is then used to assert that it matches the size of the constant. But since the types are already known to be the same, this second check is unnecessary, and skipping it also allows to skip the expensive layout query. For the unicode_normalization crate, the match checking time drops from about 3.8s to about 0.8s for me. Ref #55528 cc unicode-rs/unicode-normalization#29
Speed up item_bodies for large match statements involving regions These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead. The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though). Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them. Ref rust-lang#55528 cc unicode-rs/unicode-normalization#29 r? @nikomatsakis
Speed up item_bodies for large match statements involving regions These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead. The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though). Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them. Ref rust-lang#55528 cc unicode-rs/unicode-normalization#29 r? @nikomatsakis
|
One approach that might address this (and I'm considering for other reasons, mostly because I need raw data for HarfBuzz integration) is to use a script to generate perfect hash maps from the Unicode data, and check those hash maps into the repo. Using a crate like phf_map would work, but would add the compilation time and run time for phf_map to the total compile. I am happy to measure and PR this approach if there's interest. |
|
I'd definitely love to have script-generated phf-map stuff here. Go for it. |
Hey folks,
from time to time I see this, when I compile a project. This is like the crate that takes the longest time to finish. :/ Is there something I can help to speed it up?
Regards
The text was updated successfully, but these errors were encountered: