Dropping empty map takes time proportional to capacity

[jonhoo]

We currently iterate over the map on drop:

hashbrown/src/raw/mod.rs

Lines 1194 to 1195 in efbd036

	if mem::needs_drop::<T>() {
	for item in self.iter() {

And the iterator iterates over all the buckets, even if it knows there are no more items (RawIter::items == 0):

hashbrown/src/raw/mod.rs

Lines 1401 to 1402 in efbd036

	fn next(&mut self) -> Option<Bucket<T>> {
	if let Some(b) = self.iter.next() {

This means that code like this will unnecessarily take fairly long:

let map: HashMap<String, String> = HashMap::with_capacity(1024 * 1024);
drop(map);

The above is a little contrived, but the same occurs if the caller calls drain or clear, and then drops the map. Not sure if this is something we want to optimize for, but the fix is fairly straightforward.

[jonhoo]

I suppose this is mitigated by the fact that we iterate over the control bytes, not the actual buckets, so we're iterating through many buckets at once. Even so, it seems like it'd be nice to avoid this iteration altogether when we can?

[cuviper]

I guess the places that check needs_drop could easily check if it's already empty too.

[jonhoo]

Yup: jonhoo@8dd0412

[cuviper]

@jonhoo Are you going to submit that commit in a new pull request? I see that it was an incidental part of the closed PR #167, but that was not included in the replacement PR #175.

[jonhoo]

@cuviper Ah, good call! Submitted as #182.