Optimize extend and from_elem

[eira-fransham]

This increases the amount of unsafe code, and so should be carefully checked. However, the use of unsafe code is quite benign and depends only on the invariant that grow always succeeds (which is depended on other places in the codebase)

Benchcmp results:

 name                     preopt.bench ns/iter  postopt.bench ns/iter  diff ns/iter   diff %  speedup 
 bench_extend             277                   89                             -188  -67.87%   x 3.11  
 bench_macro_from_elem    214                   61                             -153  -71.50%   x 3.51 

I took a crack at this after noticing how awful the generated assembly for SmallVec::from_elem is even for really simple types like integers. It's still not great but it at least now for the case of Copy types it gets autovectorised. Probably someone could make it even better if they spent more time on it.

---

This change is 

[eira-fransham]

A comparison of the generated assembly for a simple (but probably common) case is here

[eira-fransham]

The reasoning behind using std::vec::from_elem/vec! over .extend(iter::repeat(..).take(..)) is that u8 and integer 0 have a fast path in vec::from_elem using ptr::write_bytes and calloc, respectively. We could conceivably also use ptr::write_bytes on u8 and 0 when the vec would be inline but that would require a nightly feature (specialisation) and would only be noticeable on huge inline arrays.

[mbrubeck]

@bors-servo r+

Thanks!

[bors-servo]

📌 Commit 401fb09 has been approved by mbrubeck

[bors-servo]

⌛ Testing commit 401fb09 with merge 8c9f6c8...

[bors-servo]

☀️ Test successful - status-travis
Approved by: mbrubeck
Pushing 8c9f6c8 to master...

[mbrubeck]

If you have a project that needs this, let us know and we can publish a release right away. (If not, it'll get published sooner or later, whenever the next release happens.)