Split `Liveness::users` into three.

[nnethercote]

This reduces memory usage on some benchmarks because no space is wasted
for padding. For a check-clean build of keccak it reduces max-rss
by 20%.

r? @nikomatsakis, but I want to do a perf run. Locally, I had these results:

• instructions: slight regression
• max-rss: big win on "Clean" builds
• faults: big win on "Clean" and "Nll" builds
• wall-time: small win on "Clean" and "Nll" builds

So I want to see how a different machine compares.

[nnethercote]

@bors try

[bors]

⌛ Trying commit efae70c with merge 7da277b...

[Mark-Simulacrum]

Is it worth also making this a bitset/bitvec?

[nnethercote]

#54208 (comment) discusses this. It would reduce memory more but increase instruction counts. Vec<bool> might be the best middle ground; let's see how the perf results look with it.

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[nnethercote]

@rust-timer build 7da277b

[rust-timer]

Success: Queued 7da277b with parent 4f921d7, comparison URL.

[nikomatsakis]

r=me if the perf results look good; note that we would like to rewrite this completely to operate on MIR. But that's a bigger job (@wesleywiser was interested, I think).

[nikomatsakis]

Perf results look like a small perf hit (5-6%) but a big memory use hit (20% etc in some cases). Interesting.

[nnethercote]

I think this is a rare case where instruction counts are misleading!

Note that keccak is the one mostly clearly affected, and inflate and clap-rs are also affected, and nothing else is. So only look at the results for those three benchmarks; the rest is noise. Also keccak-check is the only one that measures NLL.

With all that in mind, here are the results just for keccak, including check, debug and opt.

• cpu-clock: 0--6% better, 0.7% better for nll-check
• cycles: 0--4% better, 0.6% better for nll-check
• faults: 4--18% better, 6.6% better for nll-check
• instructions: 0--3% worse, 0.3% worse for nll-check
• max-rss: 0--20% better, no change for nll-check
• task-clock: 0--6% better, 0.7% better for nll-check
• wall-time: 0--6% better, 0.7% better for nll-check

Instructions gets worse, but everything else gets better. And we have a simple theoretical explanation for this: less memory traffic. So I think we should land this, but I am happy to defer to @nikomatsakis's decision.

[wesleywiser]

I think the other important bit to note is that it seems to be mostly the clean incremental builds which are showing regressions. A 5% regression on the clean incremental time is usually a very, very small amount of clock time since clean incremental builds are usually very fast.

[nnethercote]

A 5% regression on the clean incremental time is usually a very, very small

At the risk of laboring the point: it's a win, not a regression on the time. It's only a regression on instruction counts.

[wesleywiser]

Yes. Sorry if I wasn't clear: I'm very much in favor of merging this PR 👍

…

On Fri, Sep 14, 2018, 9:40 PM Nicholas Nethercote ***@***.***> wrote: A 5% regression on the clean incremental time is usually a very, very small At the risk of laboring the point: it's a win, not a regression on the *time*. It's only a regression on instruction counts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#54211 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyu2A32CcJ-YNT2Fe9kCE6Lq28iRpb2ks5ubFqfgaJpZM4Woia1> .

[nikomatsakis]

@bors r+

[bors]

📌 Commit efae70c has been approved by nikomatsakis

[nikomatsakis]

Sorry, forgot I hadn't already written that. Thanks @nnethercote for the extra details.

[bors]

⌛ Testing commit efae70c with merge 1d33aed...

[bors]

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