Revise VecPerParamSpace to use a one Vec rather than three

[pnkfelix]

In my informal measurements, this brings the peak memory usage when
building librustc from 1662M down to 1502M. Since 1662 - 1502 = 160,
this may not recover the entirety of the observed memory regression
(250M) from PR #14604. (However, according to my local measurements,
the regression when building librustc was more like 209M, so perhaps
this will still recover the lions share of the lost memory.)

[pnkfelix]

@pcwalton I think you were right, that the memory usage increase was due to malloc slop. (That, or my shrink_to_fit calls simply were not added as aggressively as they needed to be.)

[sfackler]

There are some build errors in rustdoc: https://travis-ci.org/rust-lang/rust/jobs/29158017

[huonw]

slice_from fwiw.

[pcwalton]

r=me with @huonw's comment change.

[huonw]

This did fix the vast majority of the regression: http://huonw.github.io/isrustfastyet/mem/#b00f4ec,e0d3cf6! (Saved 225 MB there, but there is some noise.)

[nikomatsakis]

Interesting. This provides some evidence for a hypothesis of mine: that aggressive use of Box<[T]> to reflect vectors we were no longer planning to grow and Vec<T> for those we are may help memory usage overall. I've heard similar comments about the need to shrink to fit in Java apps to avoid memory bloat.

[pnkfelix]

@nikomatsakis if that hypothesis were true, then it would have sufficed to add shrink_to_fit invocations at all the correct locations, to force the Vec's down to the proper size, correct? Or are you foreseeing some other benefit of Box<[T]> that is not captured by aggressive use of the shrink_to_fit method?

I mention this because adding shrink_to_fit calls (though admittedly not as aggressively as I could have), was the first thing I tried, and that did not seem to help very much. this is what led to @pcwalton and I discussing whether the cause was due to "malloc slop" (i.e. overhead from simply having several distinct malloc'ed blocks of memory and the fragmentation and/or metadata associated with those blocks, versus folding the distinct blocks together into one contiguous chunk.)

[nikomatsakis]

I mention this because adding shrink_to_fit calls (though
admittedly not as aggressively as I could have), was the first
thing I tried, and that did not seem to help very much. this is
what led to @pcwalton and I
discussing
whether the cause was due to "malloc slop" (i.e. overhead from
simply having several distinct malloc'ed blocks of memory and the
fragmentation and/or metadata associated with those blocks, versus
folding the distinct blocks together into one contiguous chunk.)

I see, I didn't really read the patch and misunderstood what it did. Interesting!