Experiment with using `HashMap::with_capacity` throughout the compiler

[jyn514]

We have found several times that rustc's performance is basically a giant benchmark of our hashmaps. @orlp notes:

Resizing the hash table during building basically means all the work you did up until that point was to calculate a single boolean value: your capacity wasn't enough, and nothing else of value was done .

If we can avoid resizing our hashmaps, that will avoid quite a lot of needless hashing. Given that so much of our benchmarks are made up of hashing, that could have a significant overall performance improvement. @orlp wrote this helpful benchmark giving an idea of the order of magnitude improvement we're talking about:

fn main() {
    let start = std::time::Instant::now();
    for _ in 0..100 {
        let mut hs = HashSet::new();
        for x in 0..1_000_000 {
            hs.insert(x);
        }
        std::hint::black_box(hs);
    }
    println!("no capacity: {:?}", start.elapsed());

    let start = std::time::Instant::now();
    for _ in 0..100 {
        let mut hs = HashSet::with_capacity(1_000_000);
        for x in 0..1_000_000 {
            hs.insert(x);
        }
        std::hint::black_box(hs);
    }
    println!("perfect capacity: {:?}", start.elapsed());

    let start = std::time::Instant::now();
    for _ in 0..100 {
        let mut hs = HashSet::with_capacity(1_000_000);
        for x in 0..hs.capacity() + 1 {
            hs.insert(x);
        }
        std::hint::black_box(hs);
    }
    println!("worst-case underestimation: {:?}", start.elapsed());

    let start = std::time::Instant::now();
    for _ in 0..100 {
        let hasher = FixedState::with_seed(42);
        let mut sketch = CardinalitySketch::new();
        for x in 0..1_000_000 {
            sketch.insert(hasher.hash_one(x));
        }

        let mut hs = HashSet::with_capacity(sketch.estimate() * 5 / 4);
        for x in 0..1_000_000 {
            hs.insert(x);
        }
        std::hint::black_box(hs);
    }
    println!("cardinality estimate: {:?}", start.elapsed());
}

no capacity: 1.582721584s
perfect capacity: 337.567208ms
worst-case underestimation: 2.038280209s
cardinality estimate: 412.6665ms

---

There are two main parts to this issue.

1. Determine whether making changes here will be an improvement (I feel fairly confident about this, but it's nice to have data). This could be done by either:
   • Looking at a performance sample to see which functions are hot, and seeing how much time resizing functions are taking up (i think the relevant function is hashbrown::raw::RawTableInner::resize_inner). This will also let us know which maps are most in need of pre-allocating (which will be helpful in part 2).
   • Using a very liberal estimate of how much capacity we need (say, 10x the number of items in the crate for each hashmap) and doing a perf run on that to see if we get any improvements.
2. Determining an upper bound for each hashmap so we don't allocate more memory than we need. I expect this to be the hard part.

(and then, of course, actually switching to using with_capacity)

@rustbot label T-compiler I-slow E-medium E-mentor

[steffahn]

Do note that parts of this test case are flawed. 0..hs.capacity() + 1 is way larger than 1_000_000. (It’s 1_835_009.)

---

Also, I had played around with these test cases – and variations of them – for a few hours when they were first shared, and noticed that some performance could already be gained by skipping a few steps resize steps. By doing some capacity == len checks before an insert and reserving 2 * capacity + 1 extra space, we'd do x4 resizes instead of x2. In a similar way, one can do x8 as well.

I also tested some code where hash values where cached, but that ended up being less clearly beneficial, even with the expensive default hasher, at least in this test case. It may very well be the case that it's more effective for cases where the maps contains any more complex types¹ than simple word- or pointer-sized ones, where hashing could involve touching more data and/or following some indirection.

Footnotes

1. here, complex types behind a simple interned pointer don't count if they only hash the pointer ~ but e.g. the maps that do the interning do need to calculate real hashes that are (at least slightly) more nontrivial ↩

[ARandomDev99]

@rustbot claim

I'm interested in working on this. I've made some contributions to rust-lang/rust-clippy before. Is that experience sufficient to work with a mentor or should I be looking for even easier issues?

[Kobzol]

I think that analysing the hashmap usage should be doable. You can build the compiler with debuginfo (rust.debuginfo-level = "line-tables-only") and then profile the compiler e.g. using perf or Cachegrind (https://github.com/rust-lang/rustc-perf/tree/master/collector#profiling) to find the occurrences of the resize_inner function.