javascript - Why using for is faster than some() or filter() -

i tried 2 different way , surprised performance result :

i have 2 versions of function :

using for :

$scope.hasblockresult = function (is, area, block) {     if (!block)         return false;     (var = 0; < $scope.filteredcartolist.length; i++) {         if ($scope.filteredcartolist[i].informationsystem ===              && $scope.filteredcartolist[i].area === area              && $scope.filteredcartolist[i].block === block)             return true;     }     return false; }; 

and using some() function :

$scope.hasblockresult = function (is, area, block) {     if (!block)         return false;      return ($scope.filteredcartolist.some(function (carto) {         if (carto.informationsystem === && carto.area === area && carto.block === block)             return true;         return false;     })); }; 

same thing here :

between for :

for (var = 0; < $scope.filteredcartolist.length; i++) {     if ($scope.filteredcartolist[i].informationsystem ==          && $scope.filteredcartolist[i].type != 'am'          && $scope.filteredcartolist[i].type != 'if'          && $scope.filteredcartolist[i].area == area          && $scope.filteredcartolist[i].block == block)         $scope.resultlist.push($scope.filteredcartolist[i]);     } 

and filter() :

$scope.resultlist = $scope.filteredcartolist.filter(function (carto) {     if (carto.informationsystem ==          && carto.type != 'am'          && carto.type != 'if'          && carto.area == area          && carto.block == block)         return true;     return false; }); 

i expected filter() , some() methods faster for method, in both case, according angularjs batarang performance tab, foris faster.

given article posted in comments (and associated benchmarks), can safely conclude massive difference noticing because benchmarks you're looking @ crap.

• the benchmarks aren't programmed equal. loop example uses console.timeend , console.log, both of notoriously inefficient.
• the some example performs type co-ercion.
• all of tests performing string concatenation within loops. doesn't impact fairness of benchmarks mean testing string concatenation and access methods.

now, array of 300 items , 300 iterations, results when these factors eliminated on 8gb ddr3 intel i5 laptop on chrome 44 follows (re-ordered in terms of slowest fastest):

object average 0.0010666643114139636 seek average 0.00593666957380871 loop average 0.008436664550875625 average 0.013993332007279 filter average 0.02592999837361276 

these expected, , here why:

seek

seek implemented using indexof locate element , accessing element @ direct array index. actual method of determining whether equates value implemented browser don't know how method works 1 assume browser-implemented, optimized version of some.

loop

the loop approach slower because unlike 'seek' test, loop test iterates on entire array , both array access , object access. seek method doesn't this. breaks out after finding element. don't know if quite explain discrepancy between seek , loop, though not surprised. again, though, seek browser-implemented , able optimized - loop optimized still have offset fact can optimized less seek.

some

some has overhead of function invocation invoked every single iteration. in addition, cannot optimized @ jit compiler because jit compiler doesn't know you're going pass some.

filter

filter iterates entire array before returning, shouldn't surprise.

object access

in chrome @ least, object access blazingly fast because of way objects compiled under hood classes. worth mentioning arrays objects , use same method.

tldr these benchmarks pretty worthless because aren't programmed equal , none of them testing method of access testing other stuff string concatenation , console.log speed. 300 items in array small, you'd want larger array definitive results.