Shrink overallocated capacity if a number gets a lot smaller.

[tczajka]

If a number gets below 1/4 of capacity, shrink_to_fit. Since Vec grows by 2, this amortizes well
for any sequence of sizes.

[cuviper]

Do you have any real-world data supporting this? I'm hoping to see both memory use and performance impact. The performance is probably fine, since it's a simple comparison of local fields, but it would be good to have measurements.

[tczajka]

This is primarily motivated by my desire to have a theoretical upper bound worst case guarantee, rather than a gain on average.

If I am doing some huge calculation, and have n numbers of m bits, it is important for me to have an upper bound that says I'll be using O(nm) bits of allocated memory. Otherwise, using the library for such calculations would give me pause because I would never know if memory use won't blow up, have to trust a heuristic when it could be a guarantee.

Most benchmarks show no impact, some benchmarks show ~5% degradation (in CPU).

I suspect the impact is not because of the check, but because of the actual shrinking. Plus when we actually do shrink, there is no extra space left, and sometimes having extra space (even one digit) helps in later operations.

So using the shrink_to API (instead of shrink_to_fit) would probably help (but it's not stable API).

Similarly, when a number is first allocated, I speculate that adding a few words of extra capacity might help performance on benchmarks.

[cuviper]

OK, I think that's reasonable, and we can keep an eye on using shrink_to and with_capacity for headroom later. I'm also not confident that all shrinking ops are covered by normalize, but there's no public promise here, so that seems ok for now.

bors r+

[bors]

Build failed:

• Test (i686)

[cuviper]

bors retry

[bors]

Build succeeded:

• Format
• No Std
• Test (1.31.0)
• Test (1.32.0)
• Test (1.34.0)
• Test (1.36.0)
• Test (beta)
• Test (i686)
• Test (nightly)
• Test (stable)