Reduce data copies during internation

[kvark]

Excessive copying in fn intern() is something we noticed yesterday with @jrmuizel .
This PR attempts to improve them in two ways (each in a separate commit):

1. reduce the Update enum size by moving the data out
2. adopt entry-like API to accommodate the common pattern of if index == v.len() { v.push(xxx) } else { v[index] = xxx; } without panics between element construction and actual assignment. It builds upon the VecHelper work of Avoid picture primitive copies via VecHelper #3362.

---

This change is 

[gw3583]

Should we confirm this is a talos win before merging?

[kvark]

@gw3583 yep, will do

Also need to confirm with the playground, since in this case (unlike with Allocation) we still have a branch separating an item constructor from the target location, even though it's not a panicing one.

[kvark]

Interestingly, a Playground experiment shows a reduction of LLVM copy calls from 4 to 0 when using this change. Seems pretty ridiculous, you are encouraged to play with it and maybe tell what I'm doing wrong :)

[jrmuizel]

Here's what my tool can tell us about where the copies are coming from:

memcpy of 402 in _ZN5entry3foo17h9b5dcf419aa0590cE @
  foo entry.rs:78
memcpy of 402 in _ZN5entry3foo17h9b5dcf419aa0590cE @
  write<entry::Thing> /rustc/400c2bc5ed292f77c49693320f4eda37bb375e90/src/libcore/ptr.rs:736
  push<entry::Thing> /rustc/400c2bc5ed292f77c49693320f4eda37bb375e90/src/liballoc/vec.rs:1003
  foo entry.rs:78
memcpy of 402 in _ZN5entry3foo17h9b5dcf419aa0590cE @
  foo entry.rs:80
memcpy of 402 in _ZN5entry3foo17h9b5dcf419aa0590cE @
  foo entry.rs:80

4 copies does seem excessive, but it is facts.

[kvark]

@jrmuizel thanks for confirmation! It's going to be a big win then :)
I'm currently having trouble getting sane talos comparisons, but I'm fairly sure this is safe to land (given the playground results so far).
Green try: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=214670152&revision=951e31ce0aa13802a0b12211f85013f57e99dad0

[jrmuizel]

It would be worth comparing before/after on webrender.ll. You should be able to avoid the verification errors by using rust nightly. (That fixed it for me)

[kvark]

@jrmuizel I'm not seeing as good of a picture as in playground (and yes, nightly works). The change of a first commit strips away a few larger memcopies, but the entry(index).set(value) patter doesn't appear to be helping in real world our case. Would be good to understand why playground results are different.

Edit: here are the dumps: memcpy-logs.zip

[jrmuizel]

I suspect we're not seeing the improvement we expect because of rust-lang/rust#56191. @nikic has a patch to llvm that might improve things here.

[kvark]

Let's not get this rot for too long.
@bors-servo r=gw3583

[bors-servo]

📌 Commit db16047 has been approved by gw3583

[bors-servo]

⌛ Testing commit db16047 with merge 1619d94...

[bors-servo]

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: gw3583
Pushing 1619d94 to master...

[kvark]

Got 5% improvement in dl_mutate from that: https://treeherder.mozilla.org/perf.html#/alerts?id=18030
🎉