Make region inference use a dirty list

[spastorino]

r? @nikomatsakis

[nikomatsakis]

Looks great. Left a small suggestion.

[nikomatsakis]

Nit: I think the dirty list ought to be either refs to constraints or indices of constraints. Since you used indices for the dependency-map, let's go with those. (It'll also avoid any borrowing issues.)

So something like:

letmut dirty_list:Vec<_> = (0..self.containts.len()).collect();

[nikomatsakis]

whileletSome(constraint_index) = dirty_list.pop(){let constraint = &self.constraints[constraint_index];
...}

[nikomatsakis]

Now this can be

ifletSome(constraint_deps) = dependency_map.get(&constraint.sup){
dirty_list.extend(constraint_deps);}

Not that it matters much, but generally invoking extend is better than for loop that calls push. This is because sometimes the iterator knows how long it will be, which lets dirty_list reallocate its backing array more efficiently.

Finally, you could simplify this further, like so:

dirty_list.extend(
dependency_map.get(&constraint.sup).unwrap_or(&vec![]));

but I'm not sure that's really clearer (arguably less so). The key here is that creating an empty vector (i.e., vec![]) is basically free -- it's just some null values, no allocation or anything. In the case where I have a "map to vec", I often do this style, under the idea that a missing entry is equivalent to an empty vector. But either way really.

[spastorino]

@nikomatsakis applied all the requested changes

[leonardo-m]

Have you run Clippy on your changes?

[nikomatsakis]

@leonardo-m why would we do that? is there some specific lint you are imagining?

fwiw, we don't usually run clippy on the compiler.

[nikomatsakis]

looking great! left 2 comments -- one is a nit, but also it's probably worth adding a bit vec to avoid duplicates as we discussed.

[nikomatsakis]

this could be &self.constraints[constraint_idx] -- no reason to copy the value out

[nikomatsakis]

as you said, it might be nice to have a bitvec storing what is already present in the dirty_list, which you would then have to clear each time we pop something out of the dirty list.

[spastorino]

@nikomatsakis ready!

[leonardo-m]

we don't usually run clippy on the compiler.

I didn't know that Clippy is not used on the compiler. Clippy gives lot of false positives, but some advice is good, so perhaps you should use Clippy...

is there some specific lint you are imagining?

I think Clippy often suggests to replace or_insert with or_insert_with

[nikomatsakis]

I think Clippy often suggests to replace or_insert with or_insert_with

Ah. This case is better left as or_insert; or at least no worse, since creating an empty vector is just some constant bits.

[nikomatsakis]

you can change this to:

if dirty_bit_vec.insert(*dep_idx){
dirty_list.push(*dep_idx);}

and save a bit of execution time.

[nikomatsakis]

Nit: I'd usually write for &dep_idx in ... just so you don't need the *dep_idx below

[nikomatsakis]

Maybe a comment here would be nice, actually. You could steal the stuff I wrote in the issue description (i.e., the example). But something like this would suffice:

---

Builds up a map from each region variable X to a vector with the indices of constraints that need to be re-evaluated when X changes. These are constraints like Y: X @ P -- so if X changed, we may need to grow Y.

[nikomatsakis]

Since I know you just stepped out, I might make these changes :)

[nikomatsakis]

Nit: this starts as all zeroes, but we really want it to start as all ones I suppose. But it won't be wrong this way, just mildly less efficient. Actually, we could "invert the sense" of the vector, and have it store a 1 if the thing is not present....call it clean_bit_vec...

[nikomatsakis]

...in that case, this would be clean_bit_vec.insert(constraint_idx);...

[nikomatsakis]

...and this would be if clean_bit_vec.remove(dep_idx) {

[nikomatsakis]

My measurements here locally using the testcase from #47267:

• No changes, no NLL: ~405 ms
• No changes, with NLL: ~608 ms, so NLL adds around 203ms
• This PR, with NLL: ~518ms, so NLL adds around 113ms

So this looks like a solid win for NLL to me! :)

These are averages of 6 runs. The results were fairly stable but jumped around some. The test case is kind of small. So take them with a grain of salt. Here is a gist with my full measurements in case you are curious, each one is labeled with the SHA1 commit hash and whether it had NLL enabled or disabled.

[nikomatsakis]

@bors r+

[bors]

📌 Commit 205eba8 has been approved by nikomatsakis

[leonardo-m]

These are averages of 6 runs. The results were fairly stable but jumped around some. The test case is kind of small.

The next Nightly I'll test this with a much larger amount of code.

[nikomatsakis]

@leonardo-m if you have a test, I can run it now.

[bors]

⌛ Testing commit 205eba8 with merge 4349bc51453d0c74495589c8036622a9b1a05726...

[bors]

💔 Test failed - status-appveyor

[kennytm]

@bors retry #46903

[bors]

⌛ Testing commit 205eba8 with merge b7d4de9edf202b3a9cd889bf038ee663aecaf573...

[bors]

💔 Test failed - status-travis

[kennytm]

@bors retry #43283

[bors]

⌛ Testing commit 205eba8 with merge 70f7d58...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 70f7d58 to master...