Consider the attached benchmark. V8 completes it immediately, whereas we and, in this form, JSC never do or at least take hours (I didn't check). If you active line 2, all browsers take long, but changing that to a non-index property doesn't cause a slowdown. JSC becomes fast if the `unshift` is removed, so it only optimizes the `shift`, apparently. JSC also has a bug in all this: the other entries aren't moved by the shift, so "foo" always stays at index 999. I only discovered this through working on Shumway compatibility with the Tamarin test suite, and it's not immediately important, but might be a symptom of a missing optimization that might we useful to have.

> JSC also has a bug in all this Did you happen to file that?

(In reply to Not doing reviews right now from comment #1) > Did you happen to file that? Good call, I did now: https://bugs.webkit.org/show_bug.cgi?id=144261

This is a sparse array issue, similar to the slice problem I fixed in bug 1087963. The meta bug for this is bug 1088189. array_shift loops from 0 to newlen, then does a slow GetElement for each of them. I think it'd be nice to have an IndexIterator thing that either loops from 0 to len, or does something smarter for sparse arrays (like what I did for slice). Then we can templatize these loops and hopefully fix this without duplicating/complicating too much code. Maybe I can make this a q3 project, if I don't have time to get to it before that.

I'm going to need to templatize these loops soon anyways so that these VM functions will be fast on unboxed arrays. I can try to abstract the index iteration as well when I do that.