Try to guess a smarter initial capacity in Vec::from_iter

[scottmcm]

Another possibility is collect could look at the upper bound and be smarter about what capacity to use? ~ #45840 (comment)

This is obviously good for hints like (60, Some(61)) where today we allocate space for 60, then double it should the additional element show up, and it'd be much better to just always allocate 61.

More nuanced are hints like (0, Some(150)), where today the code uses just the 0, and thus starts at a capacity of 1, but with this change will start at 10 instead.

This can undeniably increase memory pressure over where it is today, so I expect at least some controversy 🙂 It does use try_reserve for the allocation that's more than the lower bound, and thus shouldn't introduce new aborts, at least. And the starting point grows by the root, keeping things fairly contained: even with an hint of (0, Some(1_000_000_000)) it'll only start at 30_517.

cc @ljedrz
cc #48994

[rust-highfive]

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

[ljedrz]

This is potentially awesome not only for Option/Result::FromIterator, but also for all interators with a lower bound of zero (filters etc.). I would love to see a perf run.

[kennytm]

@bors try

[bors]

⌛ Trying commit fe30b5b with merge 8612aa2...

[bors]

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

[kennytm]

@rust-timer build 8612aa2

[rust-timer]

Success: Queued 8612aa2 with parent b47c314, comparison URL.

[kennytm]

Perf is ready.

[ljedrz]

Some greens, some reds... I'd say the results are inconclusive 🤔.

[scottmcm]

Hmm, for instructions things seem slightly worse overall :(

How reliable are the time measurements? It's interesting that webrender-clean-opt is +0.3% for instructions:u, but -1.5% for wall-time.

(Another thing that surprised me: max-rss -3.5% for webrender-debug-clean.)

I think I'll try something less complicated than the sqrt approximation for the guess; maybe it's just not worth doing that work and making LLVM compile it when people use Vec, even though it's simple integer instructions. (It's less and less helpful the larger the gap anyway.)

[scottmcm]

Ok, I've pushed a much simpler change that's only targeted at one side of the problem. Could I get another try+perf run to see whether it's fruitful overall, please?

[kennytm]

@bors try

[bors]

⌛ Trying commit aa080f4 with merge 68f12661b56cdca600c5eca7158eb2ba4026e7f3...

[bors]

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

[kennytm]

@rust-timer build 68f12661b56cdca600c5eca7158eb2ba4026e7f3

[rust-timer]

Success: Queued 68f12661b56cdca600c5eca7158eb2ba4026e7f3 with parent 26d7b64, comparison URL.

[kennytm]

Perf is ready.

[scottmcm]

Hmm, that's again a bit too mixed for me to be happy about.

I'll just close this. Anyone interested should feel free to pick this space up again; feel free to use or ignore anything I did in this PR 🙂

[qm3ster]

Is lower.saturating_add(1) actually a good idea?
There are many cases, like filtering, where the lower bound becomes 0.
Wouldn't it be better to defer allocation until there's an actual item, at which point follow Vec's built-in allocation strategy?

On the other hand, what this PR seems to be trying to solve is that it's impossible to inform the Vec of the upper bound.
Imagine Vec::from_iter((0..128).chain((0..2).filter(|_|true))) for example.
This will currently reserve 129 and then reallocate to much more than the hard upper bound, even though the very close upper bound of 130 was available. why did I rewrite the OP lol

[scottmcm]

@qm3ster Note that this PR is approaching 4 years old, so you might have meant to comment somewhere else.

But the reason the saturating_add(1) is there is that the hint it looked at after calling next for the first time. So we need to add one for the item we already have.

(And it's done this way because some iterators only really return a useful hint after looking at an item -- flat_map being the easiest example.)