如何解釋在Chrome中Array.prototype.shift的奇怪的耗時表現？

如何解釋Chrome中用數組的shift方法操作10000個數時耗時約2毫秒，操作30000個數時耗時約5毫秒，但操作60000個數時耗時卻達到2473毫秒？

測試代碼：https://github.com/ZhuoYitao/FrontEnd/blob/master/JS/arrayTimeComplexity.js

謝邀。

根本原因還是要看V8的源碼，不過大多數時候不看源碼你也可以猜出個大概。

shift()之後索引對應的元素髮生了變化，正常來說需要移動，即把 a[n + 1] 移動到 a[n]。顯然這是個很費的操作，你看到的耗時大的情形，其實是正常情況。

但是顯然這裡有優化的空間，比如如果是分配了一塊連續內存來存儲數組元素，那麼只要把起始偏移量 +1 個單位就行了。這一下子就跟 pop() 一樣快了。

何時適用這種優化，或者說何時無法使用這種優化，就得看源碼了，我翻了一下，估計是這行：https://github.com/v8/v8/blob/5.9.62/src/heap/heap.cc#L3111

即被分配進入 large object space 的無法用優化。這大概可以解釋數組大小對結果的影響。實際上在不同的版本和環境里這個數字也有所不同，題主測試的是小於等於60000的某個數字，但有些人測試的結果是 76799（Simple and concise O(n) solution），我在我的筆記本上測的結果，node 6.10.0上是76799，node 7.7.0上是63390。

以上。

上面一個是元素少得，下一個元素多得。 目測基本都消耗再 object移動上面

（PS： node 重新編譯下加入enable-vtune可以分析js源碼Enable Vtune profiling support for JavaScript to provide source code level profiling in Nodejs · Issue #3688 · nodejs/node）

沒看 Chrome 源碼，拍腦袋猜一個，跟 Cache miss 有關。