Long compilation time of crate "unicode-normalization" #55528
Labels
I-compiletime
Issue: Problems and improvements with respect to compile times.
Comments
|
building: |
|
happy to know I'm not the only one :) |
|
Is there something to do to get this triaged? |
Manishearth
added
the
I-slow
nikic
added
I-compiletime
bors
added a commit
that referenced
this issue
Jan 10, 2019
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
bors
added a commit
that referenced
this issue
Jan 12, 2019
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
pietroalbini
added a commit
to pietroalbini/rust
that referenced
this issue
Jan 12, 2019
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
Centril
added a commit
to Centril/rust
that referenced
this issue
Jan 13, 2019
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
|
Note that #57718 has some detailed profile measurements. |
|
Good news: since January 18, when this benchmark was added to the rustc-perf suite, compilation has gotten more than 2x faster. #64673 and #65089 are two recent changes that account for a big chunk of the improvements. |
|
On my box running @jens1o is this still slow for you? |
|
#65260 reduced compile time some more, by up to 7%. |
|
It is faster now, and I'm happy with it. :) Shall we close this issue? |
Yes! p.s. #65480 just chopped off another 5-7% :) |
|
#66537 chops off another 2.4%. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey folks,
I was told to create an issue here. When compiling crates, I often see this crate holding up the overall process, and because others are depending on it, it grabs one cpu core and the others are literally idle and I need to wait.
-- @Manishearth
I'd be thankful if there are some efforts to make it faster. :)
ref unicode-rs/unicode-normalization#29
The text was updated successfully, but these errors were encountered: