See https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22mac-mountainlion%22%2C%22Dromaeo%2Fjslib-traverse-jquery%3ARuns%22%5D%2C%5B%22mac-mountainlion%22%2C%22Dromaeo%2Fjslib-traverse-prototype%3ARuns%22%5D%2C%5B%22mac-lion%22%2C%22Dromaeo%2Fjslib-traverse-jquery%3ARuns%22%5D%5D&days=218&zoom=%5B1379161460728.1538%2C1380252801171.3845%5D http://trac.webkit.org/log/?rev=156215&stop_rev=156206&verbose=on
<rdar://problem/15710364>
I've bisected locally. This regression is caused by http://trac.webkit.org/changeset/156214.
Created attachment 219817 [details] A/B test result
*** Bug 125953 has been marked as a duplicate of this bug. ***
The original bug was that we would be in the middle of copying, see and hole and we realize we should have done something else, and then we start copying all over again. The fix was a simple one: first check if there's a hole, then do the copy. So you're always doing two passes over the array. If we want to fix this regression then we need a way to start copying and then gracefully fail when we see a hole without forgetting that we had already started copying.
(In reply to comment #5) > The original bug was that we would be in the middle of copying, see and hole and we realize we should have done something else, and then we start copying all over again. > ..see a hole, realize we should... Jeez.
I think we need to come up with some strategy to improve the performance of jslib-traverse-jquery because we've regressed this particular test thrice: https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22mac-mountainlion%22%2C%22Dromaeo%2Fjslib-traverse-jquery%3ARuns%22%5D%5D&days=200 We used to get 22 runs/s but now we're getting 17 runs/s, a hopping 30% regression in the total :( Perhaps we can improve elsewhere to compensate?