Extend impls for HeaderMap don't use reserve

[jplatte]

Is it intentional that the Extend implementations for HeaderMap don't call .reserve before starting iteration and insertion?

[seanmonstar]

I don't recall that it's intentional. What does std do with HashMap? Are you supposed to call reserve first, as a user? Or does it do it automatically? Whichever it does, we should follow suit.

[jplatte]

hashbrown does reserve up-front, though not as much as Vec because some items may be duplicate and not need extra capacity: https://docs.rs/hashbrown/0.11.2/src/hashbrown/map.rs.html#3392-3407

This leads me to a question actually, does HeaderMap's reserve reserve space for <amount> header names or <amount> header values? The docs don't say so explicitly, though I would assume the former without thinking much about it since the naive implementation of a multimap would basically be HashMap<K, Vec<V>>.

[AriajSarkar]

Hi @seanmonstar and @jplatte! 👋
Note: I’m not great at formal writing, so I used AI to help format my explanation.

I've implemented a fix for this issue following the guidance to "follow suit" with HashMap's approach.

Analysis

The issue correctly identifies that HeaderMap has two Extend implementations:

1. Extend<(Option<HeaderName>, T)> - missing reserve() ❌
2. Extend<(HeaderName, T)> - already has reserve() ✅

Solution

I've added reserve() to the first implementation using the exact same pattern from the second one, which follows hashbrown's HashMap implementation:

let reserve = if self.is_empty() {
    iter.size_hint().0
} else {
    (iter.size_hint().0 + 1) / 2
};
self.reserve(reserve);

This reserves the full hint for empty maps, or half the hint for non-empty maps (to account for potential duplicates), ensuring at most 2 reallocations in the worst case.

Testing

• ✅ All 396 existing tests pass (127 unit + 31 integration + 228 doc + 10 other)
• ✅ No behavioral changes - pure performance optimization
• ✅ No breaking changes

Next Steps

I have a branch ready with this fix. Would you like me to open a PR, or would you prefer to review the approach first?

AriajSarkar@c449d82

The implementation is straightforward and directly addresses the issue by making both Extend implementations consistent with each other and with the HashMap pattern.

[seanmonstar]

Thanks for taking a look, go ahead and submit your fix as a PR.

(In general, I don't have a problem with people using LLMs to help with English, but they tend to output too much, if you want to prompt it to be more concise, that'd help.)