Is lodash _.size() faster than JS length property?

Question

The article (link below) suggests that using the length property on a string creates an object reference which unnecessarily slows the function down.

http://www.webreference.com/programming/javascript/jkm3/2.html

In this context, what is the advantage of using lodash _.size() ? Does it perform any differently than the (native...?) length property?

If you're counting an array or keys in an object, is there any benefit to using lodash size instead of the length property?

Answer 1

From the lodash sources, _.size() is implemented as:

function size(collection) {   var length = collection ? getLength(collection) : 0;   return isLength(length) ? length : keys(collection).length; } 

For an array, the first line is indirectly doing collection.length so that _.size() is, if anything, a little (tiny) bit slower.

In the performance article, the performance problem is that the property lookup of length is being used when a number on the stack could have been used to achieve the same goal. In other words, the solution was not to look for a faster property, but to avoid the property altogether when it could be done.

Answer 2

The size() function is most useful in chains, when you need the size of the result. There's no point in unpacking everything using value() just to get the size. For example:

_(_.range(10))     .filter(function(item) { return item % 2; })     .size(); 

As opposed to the longer form:

_(_.range(10))     .filter(function(item) { return item % 2; })     .value()     .length; 

This function also makes it easier to find the size of an object:

_.size({ a: 1, b: 2 }); 

As opposed to:

Object.keys({ a: 1, b: 2 }).length; 

size() is about code brevity, not performance.