Crate with large static map in external crate fails to compile #40355
Labels
I-slow
Issue: Problems and improvements with respect to performance of generated code.
P-high
High priority
regression-from-stable-to-beta
Performance or correctness regression from stable to beta.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
Seems like a regression in the |
arielb1
added
I-slow
|
last good: These are the changes. There’s a number of possibly relevant ones. |
|
cc @rust-lang/compiler Maybe someone else knows something. |
|
Here's a backtrace of where the compiler is after running for a couple of minutes. |
|
This is #38776 (probably this change) - reverting that PR makes things fast again. |
|
Huh, why would that not hit caches? Is it because the type needs to be inferred? |
|
@eddyb I don't know, I think the current system for binops can also be slow sometimes. It's been vaguely on my list to investigate that a bit more and see if there are fast paths we can do. |
|
I think this is encountering the O(n^2) quadratic blowup case badly. In that case, we'll have to add "off-main-path" is-not-unsized "obligations". |
|
We could also try to solve the O(n^2)ness at the root: for each type variable, maintain a list of obligations it's contained in. Also maintain a stream of changes to type variables. When reselecting, walk over the stream and "unlock" all obligations with type vars inside. I am not sure whether this has better performance than the current approach in the common case. |
|
Maybe this is worth doing just for obligations with only int/float variables, tho. |
|
@arielb1 I just checked and |
|
time: 25.393; rss: 1131MB item-types checking
EDIT2: Sigh, I forgot to pull. |
|
|
What's fast: struct Map {
slice: &'static [i8]
}
static FOO: Map = Map {
slice: &[-1, -1, -1, -1 /* repeated N times */]
};What's slow: struct Map<T: 'static> {
slice: &'static [T]
}
static FOO: Map<i8> = Map {
slice: &[-1, -1, -1, -1 /* repeated N times */]
};This is #31260, I'll just go implement it 😆. EDIT: fix confirmed, PR coming up soon. |
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 17, 2017
Propagate expected type hints through struct literals. Partial fix for rust-lang#31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to. The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`. *However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes rust-lang#40355 and can be backported. r? @nikomatsakis
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 17, 2017
Propagate expected type hints through struct literals. Partial fix for rust-lang#31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to. The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`. *However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes rust-lang#40355 and can be backported. r? @nikomatsakis
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 18, 2017
Propagate expected type hints through struct literals. Partial fix for rust-lang#31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to. The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`. *However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes rust-lang#40355 and can be backported. r? @nikomatsakis
arielb1
pushed a commit
to arielb1/rust
that referenced
this issue
Mar 18, 2017
Propagate expected type hints through struct literals. Partial fix for rust-lang#31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to. The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`. *However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes rust-lang#40355 and can be backported. r? @nikomatsakis
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Mar 20, 2017
Propagate expected type hints through struct literals. Partial fix for rust-lang#31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to. The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`. *However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes rust-lang#40355 and can be backported. r? @nikomatsakis
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Possibly related: #36799
When attempting to compile https://github.com/urschrei/lonlat_bng using
cargo testorcargo build --releaseon OS X using beta (5276ba7) or nightly (b1e3176), the compilation step doesn't complete (or at least, it hadn't after around 11 hours). It also times out on Linux Nightly and Beta, using Travis.On current OS X Stable (021bd29), it compiles as expected within ~95s locally, and on Linux Stable, using Travis, although
rustdocfor the external crate fails with an OOM error on Linux.This is probably due to the size of the static map in the external crate (https://github.com/urschrei/ostn15_phf), which is around 40.9mb.
The text was updated successfully, but these errors were encountered: