Improve time complexity of equality relations

[Marwes]

This PR adds a UnificationTable to the TypeVariableTable type which is used store information about variable equality instead of just storing them in a vector for later processing. By using a UnificationTable equality relations can be resolved in O(n) (for all realistic values of n) rather than O(n!) which can give massive speedups in certain cases (see combine as an example).

Link to combine: https://github.com/Marwes/combine

[Marwes]

This is an alternative solution to the same compilation time problem as in #32042. This on the other tackles the problem in a much more complex way which may add a slight slow down for typechecking in the normal case due to its increased complexity (most of the time n is very small leading to the old and simpler way being slightly faster).

This change essentially makes it so that when two variables are stated to be equal the relation is immediately created and made available to users of the TypeVariableTable which is quite different from the old approach which would not make this connection until one of the variables was assigned a concrete type (and even then it would take time for it to propagate to all the variables). As that is a rather large change I cannot say for certain if I missed some subtlety in how it works so hopefully someone with more experienced can give some insight. I do however think it should only change the order of when errors are detected.

Minimal example which displays this issue, add on more calls to the chain method to make it more noticeable.

fn main() {
    let _ = test(Some(0).into_iter());
}

trait Parser {
    type Input: Iterator;
    type Output;
    fn parse(self, input: Self::Input) -> Result<(Self::Output, Self::Input), ()>;
    fn chain<P>(self, p: P) -> Chain<Self, P> where Self: Sized {
        Chain(self, p)
    }
}

struct Token<T>(T::Item) where T: Iterator;

impl<T> Parser for Token<T> where T: Iterator {
    type Input = T;
    type Output = T::Item;
    fn parse(self, _input: Self::Input) -> Result<(Self::Output, Self::Input), ()> {
        Err(())
    }
}

struct Chain<L, R>(L, R);

impl<L, R> Parser for Chain<L, R> where L: Parser, R: Parser<Input = L::Input> {
    type Input = L::Input;
    type Output = (L::Output, R::Output);
    fn parse(self, _input: Self::Input) -> Result<(Self::Output, Self::Input), ()> {
        Err(())
    }
}

fn test<I>(i: I) -> Result<((), I), ()> where I: Iterator<Item = i32> {
    Chain(Token(0), Token(1))
        .chain(Chain(Token(0), Token(1)))
        .chain(Chain(Token(0), Token(1)))
        .chain(Chain(Token(0), Token(1)))
        .chain(Chain(Token(0), Token(1)))
        .chain(Chain(Token(0), Token(1)))
        .chain(Chain(Token(0), Token(1)))
        .chain(Chain(Token(0), Token(1)))
        .chain(Chain(Token(0), Token(1)))
        .parse(i)
        .map(|(_, i)| ((), i))
}

Fixes #21231

[alexcrichton]

r? @nikomatsakis

[Marwes]

This does not currently fix the compile times of the example @asajeffrey posted. I do however have a theory about that specific issue which I will investigate closer. If it turns out to be correct then this PR (or something close to it) is almost guaranteed to be necessary to solved the issue).

In the iterator chaining example (pasted below) the main problem is the large number of instantiations of associated types. #20304 indicates that this should be possible to solve by adding making normalize_projection_type memorized. While it is easy to add a FnvHashMap<ProjectionTy, Ty> which stores the result of each call it won't actually help much as it may be called with <$0 as Test>::Type and <$1 as Test>::Type (where $0 is a type variable) and these two will not be found equal even if it has already been inferred that they are. By doing the equivalence relation as early as possible the chance of this kind of cache-miss can at least be reduced by always inserting types which have only "parent" variables filled.

Example:

$0 <=> $1 // $1 becomes the "parent"
normalize_projection_type($0::Type) // Cache miss, inserts $1::Type
normalize_projection_type($1::Type) // Cache hit on $1::Type

normalize_projection_type($0::Type) // Cache miss, inserts $0::Type
$0 <=> $1 // $1 becomes the "parent"
normalize_projection_type($1::Type) // Cache miss, inserts $1::Type

Ideally the second case would work as well but I am unaware of a key-value data structure where the keys may change.

fn main() {
    let iter = (0..2)
        .chain(0..2)
        .chain(0..2)
        .chain(0..2)
        .chain(0..2)
        .chain(0..2)
        .chain(0..2)
        .chain(0..2)
        .chain(0..2)
        .chain(0..2)
        .chain(0..2);
    for i in iter { println!("{:?}", i); }
}

[arielb1]

That looks +1. I want to check how this affects performance on normal rustc builds.

[Marwes]

Pushed a minor change to avoid retrieving the root variable more than is necessary. Also renamed "parent_*" to "root_" as that seems more like the naming scheme in the unification table module.

[bors]

☔ The latest upstream changes (presumably #32056) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

@Marwes I didn't get a chance to read this patch in detail yet, but I was actually thinking of taking precisely this same approach for other independent reasons, so I'm definitely +1 on the overall idea. I'll try to take a look tomorrow!

[nikomatsakis]

Can you add the test case that you mention here into the repo? How about making a directory src/test/run-pass/bench and putting it in there? I can move a few other similar "benchmark" test cases into there. It's great to be able to check these when later refactoring things.

Another option -- perhaps a better option -- is to add the test case to as a PR to https://github.com/nrc/rustc-perf. I plan to do this in any case though =) along with a few other similar microbenchmarks for extreme cases.

[Marwes]

Can you add the test case that you mention here into the repo?

I assume that it won't be run during make check? While this significantly reduces type checking times it does not fix them completely as the example is also affected by #20304 so It might actually slow down check times otherwise.

[Marwes]

@nikomatsakis I read all your comments and I will go through and do a commit tomorrow.

[Marwes]

Those two commits should fix all nits. I can rebase and squash all commits if that would be cleaner.

I tried an alternate way of handling relations as well. I figured it may be more memory efficient to move the non-root relation vector into the RelateRange action so that it can be quickly rolled back while also allowing the vector to be deallocated. Instead of a decrease I got an increase in memory use which seems odd so either I am missing something or the undo log is never cleared. I may investigate this a bit further but this PR should should be ok modulo a rebase.

[Marwes]

Seems that make tidy fails because of the missing license. I tried copying the license from a different file but that does not solve it. Any ideas?

[steveklabnik]

@Marwes, src/test/run-pass/bench/issue-32062.rs doesn't seem to have a license at the top. Maybe you forgot to push again after you tried to fix it?

[Marwes]

@steveklabnik I only added it locally and tested running make tidy after which it still failed. Anyway, turns out the file had CRLF line endings locally as I had copy pasted the example from this PR. Fixed that and amended the commit so it should pass now.

[Marwes]

I am not able to reproduce the current travis failure locally so I am unfortunately not sure how to fix it.

[nikomatsakis]

I'm trying to reproduce locally.

[nikomatsakis]

r=me btw -- I think we can (and will) do some more work in this area, but this seems like a great step forward. But let's see if we can get to the bottom of this travis failure.

[Marwes]

Were a bit busy last week but I finally got time to go through the changes again. Turns out I missed/forgot that drop is not called until after the function is called when in argument position. Still not sure why I can't reproduce it locally (might be because of different order of iteration over a hashmap somewhere I guess?).

Let me know if I should rebase.

[nikomatsakis]

On Sun, Mar 20, 2016 at 06:38:07AM -0700, Markus Westerlind wrote:

Were a bit busy last week but I finally got time to go through the changes again. Turns out I missed/forgot that drop is not called until after the function is called when in argument position. Still not sure why I can't reproduce it locally (might be because of different order of iteration over a hashmap somewhere I guess?).

Let me know if I should rebase.

OK, please do rebase. I am also surprised that I didn't see this
locally. Perhaps a hashmap indeed.

[Marwes]

Rebased

[nikomatsakis]

@bors r+

[bors]

📌 Commit e00cdd7 has been approved by nikomatsakis

[nikomatsakis]

@Marwes it would be fantastic if you could upload that test case to https://github.com/nrc/benchmarks -- you just have to make a makefile, see this directory for an example.

[bors]

⌛ Testing commit e00cdd7 with merge 21922e1...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-64-x-armhf, auto-linux-64-x-armsf, auto-linux-64-x-freebsd, auto-linux-64-x-netbsd, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild