major treemap performance regression (and maybe regressions elsewhere?)

[thestinger]

I bisected this and determined that it was caused by 0682ad0. It seems the compiler is replacing what should be moves with copies - rather than just calling a real destructor once, the remove function does tons of paired allocation/destruction and ends up being at least 100x slower with >10k elements (it's actually worse than just a constant factor).

@nikomatsakis tested this against the patch from #4848 (by coincidence of that being what he had handy :P) and it was fixed or at least not nearly as bad, but it would probably be good to investigate this a bit more.

[nikomatsakis]

OK, if that's the offending commit, I feel pretty comfortable with letting #4848 fix it. I wrote 0682ad0 assuming that the analysis of what types should be moved by default was correct, but there turned out be a big bug in that code which #4848 fixes,so I'm not surprised that 0682ad0 would introduce a lot of copies as a result. I'm not sure why the old code didn't, but it was broken in various ways (not that the new code isn't...just hopefully fewer), some of which may have caused it to actually do the right thing by accident. :)