blocks|key|2971512|text|另一组performance+tests。循环是在一个包含百万个随机数的数组上进行的，其中包含一个空循环。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2971513|在Chrome中，具有缓存和非缓存长度的循环的时钟几乎相同，所以我猜测这是一个缓存长度的V8优化。|2971514|在Safari和Firefox中，缓存长度始终比非缓存版本快2倍左右。|2971515|entityMap|0|LINK|mutability|MUTABLE|url|http://jsperf.com/cached-array-length|1|http://code.google.com/p/v8/^0|F|5|0|0|18|2|1|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]|P|$5|K|L|M|C|$N|Q]]]]

Another set of performance <a href="http://jsperf.com/cached-array-length" rel="noreferrer">tests</a>. The loop is done over an array of million random numbers with an empty loop. 

In Chrome, the loops with cached and non-cached lengths clock pretty much the same times, so I am guessing it's a <a href="http://code.google.com/p/v8/" rel="noreferrer">V8</a> optimization to cache the length. 

In Safari and Firefox, the cached length was consistently about 2x faster than the non-cached version.

blocks|key|269189|text|TL;DR：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|269190|据我所知，数组的长度似乎是在内部缓存的(至少在V8中)。|269191|(详细信息？继续阅读：)|269192|因此，这个问题在我的脑海中徘徊了几次，我决定找出问题的根源(至少在一个实现中)。|269193|研究一下V8源代码，就得到了JSArray类。|offset|length|269194|//+The+JSArray+describes+JavaScript+Arrays
//++Such+an+array+can+be+in+one+of+two+modes:
//++++-+fast,+backing+storage+is+a+FixedArray+and+length+<=+elements.length();
//+++++++Please+note:+push+and+pop+can+be+used+to+grow+and+shrink+the+array.
//++++-+slow,+backing+storage+is+a+HashTable+with+numbers+as+keys.|code-block|syntax|javascript|269195|我假设数组元素的类型决定了它是快还是慢。我在set_has_fast_elements+(set_bit_field2(bit_field2()+%7C+(1+<<+kHasFastElements)))中设置了一个位标志，这是我在谷歌代码中查找时发现的地方，因为我在本地没有源代码。|style|CODE|269196|现在，看起来any+time+any操作是在数组上完成的(这是JSObject的子类，调用NormalizeElements()，它执行以下操作：|BOLD|269197|//+Compute+the+effective+length.
++int+length+=+IsJSArray()+?
++++++Smi::cast(JSArray::cast(this)->length())->value()+:
++++++array->length();|269198|所以，在回答你的问题时：|269199|269200|在Chrome+(或其他使用V8的浏览器)中，缓存数组的length属性似乎没有任何优势(除非您做了一些奇怪的事情，强制它为slow+(我不确定这些条件是什么)-话虽如此，我很可能会继续缓存length，直到我有机会了解所有OS浏览器实现；)|ordered-list-item|269201|在对对象执行任何操作后，length属性似乎都会更改。|269202|<代码>G220|269203|编辑：|269204|顺便说一句，似乎一个“空”数组实际上被分配了4个元素：|269205|//+Number+of+element+slots+to+pre-allocate+for+an+empty+array.
static+const+int+kPreallocatedArrayElements+=+4;|269206|我不确定一旦超出界限，数组会增加多少元素--我没有深入挖掘:)|269207|entityMap|0|LINK|mutability|MUTABLE|url|http://www.google.com/codesearch/p?hl=en#W9JxUuHYyMg/trunk/src/objects.h&q=jsarray%2520package%253ahttp://v8%255C.googlecode%255C.com&l=6057^0|0|0|0|0|E|7|0|0|0|M|L|19|1I|0|6|3|F|3|V|8|19|J|0|0|0|0|S|6|1Q|4|2N|6|0|C|6|0|0|0|3|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1T|8|@]|9|@$J|1U|K|1V|1|1W]]|A|$]]|$1|L|3|M|5|N|7|1X|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1Y|8|@$J|1Z|K|20|S|T]|$J|21|K|22|S|T]]|9|@]|A|$]]|$1|U|3|V|5|6|7|23|8|@$J|24|K|25|S|W]|$J|26|K|27|S|W]|$J|28|K|29|S|T]|$J|2A|K|2B|S|T]]|9|@]|A|$]]|$1|X|3|Y|5|N|7|2C|8|@]|9|@]|A|$O|P]]|$1|Z|3|10|5|6|7|2D|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|12|3|13|5|14|7|2F|8|@$J|2G|K|2H|S|T]|$J|2I|K|2J|S|T]|$J|2K|K|2L|S|T]]|9|@]|A|$]]|$1|15|3|16|5|14|7|2M|8|@$J|2N|K|2O|S|T]]|9|@]|A|$]]|$1|17|3|18|5|6|7|2P|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2Q|8|@$J|2R|K|2S|S|W]]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|2T|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|N|7|2U|8|@]|9|@]|A|$O|P]]|$1|1F|3|1G|5|6|7|2V|8|@]|9|@]|A|$]]|$1|1H|3|-4|5|6|7|2W|8|@]|9|@]|A|$]]]|1I|$1J|$5|1K|1L|1M|A|$1N|1O]]]]

TL;DR:

From what I can gather, it seems like the length of the array is cached internally (at least in V8)..

(Details? Read on :))

So, this question has dinged around in my head a few times and I've decided to get to the root of the problem (at least, in one implementation).

Digging around V8 source yielded the <a href="http://www.google.com/codesearch/p?hl=en#W9JxUuHYyMg/trunk/src/objects.h&amp;q=jsarray%20package%3ahttp://v8%5C.googlecode%5C.com&amp;l=6057">JSArray</a> class.

<pre><code>// The JSArray describes JavaScript Arrays
// Such an array can be in one of two modes:
// - fast, backing storage is a FixedArray and length &lt;= elements.length();
// Please note: push and pop can be used to grow and shrink the array.
// - slow, backing storage is a HashTable with numbers as keys.
</code></pre>

I'm making an assumption that the type of array elements dictates whether it's fast or slow. I got down to a bit flag being set in <code>set_has_fast_elements</code> (<code>set_bit_field2(bit_field2() | (1 &lt;&lt; kHasFastElements))</code>), which is where I figured I'd draw the digging line as I was looking in google code and don't have the source locally.

Now, it seems that any time any operation is done on the array (which is a child class of <code>JSObject</code>, a call is made to <code>NormalizeElements()</code>, which executes the following:

<pre><code>// Compute the effective length.
 int length = IsJSArray() ?
 Smi::cast(JSArray::cast(this)-&gt;length())-&gt;value() :
 array-&gt;length();
</code></pre>

So, in answering your questions:

<ol>
<li>There doesn't seem to be any advantage in Chrome (or other browsers that use V8) to caching the <code>length</code> property of an array (unless you're doing something odd that would force it to be <code>slow</code> (I'm not sure what those conditions are) - having said that, I'll most likely continue to cache <code>length</code> until I get a chance to go through all OS browser implementations ;)</li>
<li>The <code>length</code> property seems to be altered after any operation on the object.</li>
</ol>

Edit:

On a side note, it seems that an "empty" array is actually allocated to have 4 elements:

<pre><code>// Number of element slots to pre-allocate for an empty array.
static const int kPreallocatedArrayElements = 4;
</code></pre>

I'm not sure how many elements the array grows by once the bounds have been exceeded - I didn't dig that deep :)

blocks|key|272779|text|只需注意：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|272780|在一些浏览器上(我在Safari、IE和Opera中注意到了这一点)，你可以通过在for循环声明中缓存长度来提高速度：|272781|var+j;
for+(var+i+=+0,+len+=+arr.length;+i+<+len;+i%2B%2B)+{
++j+=+arr[i];
}|code-block|syntax|javascript|272782|我将上面@KooiInc的jsperf测试编辑成了add+this+case。|offset|length|272783|entityMap|0|LINK|mutability|MUTABLE|url|http://jsperf.com/array-length-in-loop/10^0|0|0|0|P|D|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|X|8|@]|9|@$K|Y|L|Z|1|10]]|A|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

Just a note:

On some browsers (I've noticed it in Safari, IE, and Opera), you can get a speed boost by caching the length inside the for loop declaration:

<pre><code>var j;
for (var i = 0, len = arr.length; i &lt; len; i++) {
 j = arr[i];
}
</code></pre>

I edited @KooiInc's jsperf test above to <a href="http://jsperf.com/array-length-in-loop/10" rel="nofollow">add this case</a>.

blocks|key|269218|text|本文通过向IRHydra请求生成的代码，研究了V8和Chrome中的自动缓存：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|269219|“|269220|+How+the+Grinch+stole+array.length+access”，作者:+Vyacheslav+Egorov|blockquote|269221|269222|269223|他发现，在某些情况下，手动缓存.length实际上增加了开销，而不是提高性能！|style|CODE|269224|但不管怎样，这种微优化不太可能为用户带来任何明显的收益。为了他们的利益，也为了你的利益，专注于清晰易读的代码，并在你的代码中使用好的数据结构和算法！|269225|Avoid+premature+optimisation：专注于优雅的代码，直到出现性能问题。只有这样，才能通过分析找出瓶颈，然后只优化那部分代码。|269226|entityMap|0|LINK|mutability|MUTABLE|url|http://mrale.ph/irhydra/2/|1|http://mrale.ph/blog/2014/12/24/array-length-caching.html|2|https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize^0|5|7|0|0|0|1|14|1|0|0|0|F|7|0|0|0|S|2|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|19|8|@]|9|@$A|1A|B|1B|1|1C]]|C|$]]|$1|I|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|1F|8|@$A|1G|B|1H|M|N]]|9|@]|C|$]]|$1|O|3|P|5|6|7|1I|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1J|8|@]|9|@$A|1K|B|1L|1|1M]]|C|$]]|$1|S|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]]|T|$U|$5|V|W|X|C|$Y|Z]]|10|$5|V|W|X|C|$Y|11]]|12|$5|V|W|X|C|$Y|13]]]]

This article investigates automatic caching in V8 and Chrome, by asking <a href="http://mrale.ph/irhydra/2/" rel="noreferrer">IRHydra</a> for the generated code:

<blockquote>
 <a href="http://mrale.ph/blog/2014/12/24/array-length-caching.html" rel="noreferrer">How the Grinch stole array.length access</a> by Vyacheslav Egorov
</blockquote>

He found that under certain conditions manually caching the <code>.length</code> actually added overhead rather than improving performance!

But anyway, this kind of micro-optimization is unlikely to achieve any noticeable gain for your users. For their benefit, and for yours, focus instead on code that is clear to read, and using good data structures and algorithms in your code!

<a href="https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize" rel="noreferrer">Avoid premature optimisation</a>: Focus on elegant code until a performance issue arises. Only then, seek out the bottleneck through profiling, and then optimise just that part of the code.

blocks|key|2971607|text|请注意，不要认为所有可迭代集合都是这样的。例如，缓存HTMLCollection的长度在Chrome+(版本41)中快65%25，在Firefox+(版本36)中快35%25。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2971608|http://jsperf.com/array-length-in-loop-dom|offset|length|2971609|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|16|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

Take care not to assume that this is true for all iterable collections. For example caching the length of an HTMLCollection is 65% faster in Chrome (Version 41) and 35% faster in Firefox (Version 36).

<a href="http://jsperf.com/array-length-in-loop-dom" rel="nofollow">http://jsperf.com/array-length-in-loop-dom</a>

I always assumed caching the length of an array in JavaScript is a good idea (especially in the condition of a <code>for</code> loop) because of the expensiveness of calculating the length of an array.
<h3>Example</h3>
<pre><code>for (var i = 0; i &lt; arr.length; i++) { }

// vs

for (var i = 0, arrLength = arr.length; i &lt; arrLength; i++) { }
</code></pre>
However, I thought perhaps the <code>length</code> property is only updated on creation and alteration of the array. Therefore, reading it shouldn't be too expensive an operation as opposed to reading it stored in a variable (as opposed to other methods in other languages that may need to seek in memory to find the end of something, e.g. <code>strlen()</code> in C).
I have two questions. I am also interested in how this works, so please don't hit me with the premature optimisation stick.
Assume the JavaScript engines in browsers.
<ol>
<li>Is there any advantage to caching the <code>length</code> property of an array in JavaScript? Is there much more involved in reading a local variable over an object's property?</li>
<li>Is the <code>length</code> property simply altered on creation and on <code>shift()</code> and <code>pop()</code> type methods that don't return a new array and otherwise simply stored as an integer?</li>
</ol>

Is reading the `length` property of an array really that expensive an operation in JavaScript?

数据结构

我一直认为在JavaScript中缓存数组的长度是一个好主意(特别是在for循环的情况下)，因为计算数组长度的开销很大。示例for (var i = 0; i < arr.length; i++) { }// vsfor (var i = 0, arrLength = arr.length; i < arrLength...

问在JavaScript中读取数组的`length`属性真的是一个开销很大的操作吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在JavaScript中读取数组的`length`属性真的是一个开销很大的操作吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在JavaScript中读取数组的`length`属性真的是一个开销很大的操作吗？
EN