La Performance de jQuery.grep vs Tableau.filtre

Dans un question il a été discuté sur la façon de jQuery et natif JS serait exécuter les uns contre les autres.

Bien que la vanille solution exécute beaucoup plus rapidement car il ne traite pas l'ensemble du tableau, j'ai proposé l'utilisation de Array.filter qui j'étais assez confiant serait au moins plus vite que $.grep.

Étonnamment après l'ajout à l'épreuve m'a appris une leçon: Testsuite

Edgecases bien sûr d'avoir un résultat différent.

Toute personne ayant une idée de pourquoi $.grep est censé être plus de 3 fois plus rapide que la méthode native Arrray.filter?

Edit: j'ai modifié le test à utiliser le filtre cale de MDN et les résultats sont assez intéressants:

Chrome: Même MDN cale est plus rapide que la méthode native, jQuery avance
Firefox: cale un peu plus lente que la méthode native, jQuery avance

et enfin à un tel résultat, je m'attendais à voir dans

Internet Explorer:
natif méthode est la plus rapide, jQuery, la cale est plus lent (c'est peut-être simplement le résultat de l'IEs plutôt faible JS-moteur...)

InformationsquelleAutor Christoph | 2013-02-01

14

Que l'on trouve sur ce blog (qui fait aussi le même genre de tests):
Si vous lisez la documentation pour filtre, vous verrez pourquoi il est beaucoup plus lent.
1. Il ignore les valeurs supprimées et les lacunes dans le tableau
2. Il peut éventuellement définit le contexte d'exécution de la fonction de prédicat
3. Il empêche la fonction de prédicat de la mutation des données
- Ce n'est pas Array.filter mise en œuvre, c'est juste une solution de repli. Array.filter est une méthode native mis en œuvre dans le JS moteur (C++).
- Encore: pourquoi le filtre natif méthode évidemment plus lent que celui de jQuery.grep?
- Mise à jour de ma réponse (désolé pour la confusion)
- mise à jour de ma réponse... de la JS-shim est plus performante que la méthode native...pourquoi???
- Dans FF18, le natif des performances légèrement meilleures que la cale, mais jQuery est toujours sur le dessus 3 fois plus rapide.
- "Il empêche la fonction de prédicat de la mutation des données" - je ne peux pas les trouver, ni sur le MDC, ni dans l'ES spec.
- Je pense que c'est parce que un nouvelles tableau est créé, à la place de l'ancien en cours de modification.
InformationsquelleAutor MarcoK
8

Section 15.4.4.20 de l'ECMAScript 5.1 spec définit Array.prototype.filter(callbackfn, thisArg) comme suit:

callbackfn doit être une fonction qui accepte trois arguments et
renvoie une valeur qui est contrainte à la valeur Booléenne true ou
false. filter appels callbackfn une fois pour chaque élément dans la
tableau, dans l'ordre croissant, et construit un nouveau tableau de tous les
les valeurs pour lesquelles callbackfn retourne true. callbackfn est appelé
uniquement pour les éléments de la matrice qui existent réellement; il n'est pas appelé
pour les éléments manquants de la matrice.

Si un thisArg paramètre est fourni, il sera utilisé comme this
valeur pour chaque invocation de callbackfn. Si elle n'est pas,
undefined est utilisé à la place.

callbackfn est appelée avec trois arguments: la valeur de l'élément,
l'indice de l'élément, et l'objet en cours de traversée.

filter n'est pas directement la mutation de l'objet sur lequel elle est appelée, mais
l'objet peut être muté par les appels à callbackfn.

La gamme des éléments transformés par le filtre est défini avant le premier appel
pour callbackfn. Les éléments qui sont ajoutés à la matrice après l'
appel à filtre commence ne sera pas visité par callbackfn. Si existants
les éléments de la matrice sont changé leur valeur en tant que passé à
callbackfn sera la valeur au moment de filtre visites eux;
les éléments qui sont supprimés à la suite de l'appel à filtre commence et avant
visité ne sont pas visités.

Ce qui en soi est déjà beaucoup de travail, beaucoup de mesures que le moteur ECMAScript besoin pour exécuter.

Puis il poursuit en disant que les suivantes:

Lorsque le filtre de la méthode est appelée avec un ou deux arguments, le
les étapes suivantes sont prises:

Laisser O être le résultat de l'appel ToObject passage de la this valeur que la
argument.
Laissez lenValue être le résultat de l'appel de la [[Get]] interne
méthode de O avec l'argument length.
Laissez len être ToUint32(lenValue).
Si IsCallable(callbackfn) est faux, jeter une exception TypeError. Si
thisArg a été fourni, T est thisArg; else T est pas défini. Laisser Un
un nouveau tableau créé, comme si par l'expression new Array() où la Matrice de
est le standard intégré dans le constructeur de ce nom. Soit k 0. Laissez
à 0. Répétez, tandis que k < len Laisser Pk être ToString(k). Laissez kPresent être
le résultat de l'appel de la [[HasProperty]] méthode interne de O avec
l'argument de Pk. Si kPresent est vrai, alors Laissez kValue être le résultat de
l'appel de la [[Get]] méthode interne de O avec l'argument Pk. Laissez
sélectionnés être le résultat de l'appel de la [[Appel]] méthode interne de
callbackfn avec T comme cette valeur et de la liste d'arguments contenant
kValue, k, et O. Si ToBoolean(sélectionné) est vrai, alors Appelez le
[[DefineOwnProperty]] méthode interne d'Un avec des arguments
ToString(de), Descripteur de Propriété {[[Valeur]]: kValue, [[Écriture]]:
vrai, [[Énumération]]: true, [[Configurable]]: true}, et le faux.
Augmentation de 1. Augmentation de k par 1. De Retour A.

La longueur de la propriété de
la méthode de filtrage est 1.

REMARQUE La fonction de filtre est volontairement générique; il ne nécessite pas de
que sa cette valeur d'être un objet de Tableau. Par conséquent, il peut être
transféré à d'autres types d'objets pour les utiliser comme une méthode. Si l'
fonction de filtre peut être appliqué avec succès à un objet hôte est
dépendant de l'implémentation.

Des choses à noter à propos de cet algorithme:
- Il empêche la fonction de prédicat de la mutation des données
- Il peut éventuellement définit le contexte d'exécution de la fonction de prédicat
- Il ignore les valeurs supprimées et les lacunes dans le tableau
Dans beaucoup de cas, aucune de ces choses sont nécessaires. Ainsi, lors de l'écriture d'un filter méthode de votre propre, la plupart du temps vous ne serait même pas pris la peine d'effectuer ces étapes.

Chaque ES5.1-conforme moteur JavaScript doit être conforme à celle de l'algorithme, et doit donc effectuer toutes ces étapes chaque fois que vous utilisez Array#filter.

Il ne faut pas s'étonner que tout écrit sur mesure méthode qui ne réalise qu'une partie de ces étapes sera plus rapide 🙂

Si vous écrivez votre propre filter fonction, les chances sont qu'il ne va pas être aussi complexe que l'algorithme ci-dessus. Peut-être que vous ne serez pas la conversion de la matrice à un objet, comme selon le cas d'utilisation, il peut ne pas être nécessaire de filtrer le tableau.
- eh bien, en chrome, même le js-shim conforme exactement à l'ES5-spec est plus rapide que la fonction native...
- Ce n'est pas confirmant exactement pour l'ES spec. J'ai seulement jeté un coup d'oeil au code pendant quelques secondes et déjà trouvé quelque chose, il ne différemment de la façon dont il est défini dans l'ES spec. Étape 4: “si IsCallable(callbackfn) est false, jeter un TypeError exception.” La cale vérifie cela en utilisant typeof, qui diffère de la IsCallable de l'algorithme dans le spec. Le résultat final est le même, mais c'est un tout autre chemin d'accès au code, potentiellement différente de la performance de coût.
InformationsquelleAutor Mathias Bynens
3

J'ai trouvé quelque chose d'intéressant. Comme l'a expliqué MarcoK, $.grep est juste une mise en œuvre simple avec une boucle for. Le filtre est plus lente dans la plupart des cas, de sorte que la mise en œuvre doit être différent. Je crois que j'ai trouvé la réponse:
```
function seak (e) { return e === 3; }

var array = [1,2,3,4,5,6,7,8,9,0], i, before;
array[10000] = 20; //This makes it slow, $.grep now has to iterate 10000 times.
before = new Date();

//Perform natively a couple of times.
for(i=0;i<10000;i++){
    array.filter(seak);
}

document.write('<div>took: ' + (new Date() - before) + '</div>'); //took: 8515 ms (8s)

before = new Date();

//Perform with JQuery a couple of times
for(i=0;i<10000;i++){
    $.grep(array, seak);
}
document.write('<div>took: ' + (new Date() - before) + '</div>'); //took: 51790 ms  (51s)
```
Le natif de "filtre" est beaucoup plus rapide dans ce cas. Je pense donc qu'il réitère les propriétés plutôt que l'index du tableau.

Maintenant revenons aux "grands" problèmes ;).
- C'est en aucune façon une réponse que plutôt une vague assupmtion. Bien sûr, indices de tableau ne sont que de simples propriétés de l'objet array, mais vous avez accès à travers support de la notation. Donc, il n'a pas de sens de parler de propriétés ou d'indices - même. La seule différence est que Array.prototype.filter ignore les lacunes dans le tableau et n'invoque la fonction de filtre 11 fois, tandis que grep invoque 10001 fois.
- Aussi, je ne peut en aucune manière de confirmer votre temps, grep est lent, mais seulement jusqu'à 50% de la version native ... jsperf.com/grep-vs-pure-js/7
InformationsquelleAutor nicojs
2

N'est pas votre script de mal?

Pour array.filter vous faites la mesure 1000 fois et de le présenter pour prendre la somme divisée par 1000

Pour JQuery.grep vous faites de la mesure 1 du temps et de la présenter pour prendre la somme divisée par 1000.

Que signifie votre commande grep est en fait 1000 fois plus lent que la valeur que vous utilisez à des fins de comparaison.

Test rapide dans firefox donne:
```
Machine 1:
average filter - 3.864
average grep - 4.472

Machine2:
average filter - 1.086
average grep - 1.314
```
Test rapide en chrome donne:
```
Machine 1:
average filter - 69.095
average grep - 34.077

Machine2:
average filter - 18.726
average grep - 9.163
```
Conclusion dans firefox (50.0) est beaucoup plus rapide pour votre chemin de code, et le filtre est d'environ 10 à 15% plus rapide que celui de jquery.grep.

Chrome est très lente pour votre chemin de code, mais grep semble être 50% plus rapide que le tableau.filtre ici en fait de 900% plus lent que firefox exécuter.

InformationsquelleAutor Riek Steenwegen

-1

TLDR; Grep est plus rapide par un séisme de magnitude... (un indice sur le pourquoi du peuvent être trouvés ici)

Il me semble .filtre de forces, c'est ce pour Objet de vérifications de la
rappel IsCallable et jeux de ça ainsi que la vérification des
l'existence de la propriété à chaque itération alors que .grep suppose et
saute de ces étapes, ce qui signifie qu'il est un peu moins passe.

Voici le script que j'ai utilisé pour le test:

JS:

function test(){
var array = [];
for(var i = 0; i<1000000; i++)
{
array.push(i);
}

var filterResult = []
for (var i = 0; i < 1000; i++){
var stime = new Date();
var filter = array.filter(o => o == 99999);
filterResult.push(new Date() - stime);
}

var grepResult = [];
var stime = new Date();
var grep = $.grep(array,function(i,o){
return o == 99999;
});
grepResult.push(new Date() - stime);

$('p').text('average filter - '+(filterResult.reduce((pv,cv)=>{ return pv +cv},0)/1000))
$('div').text('average grep - '+(grepResult.reduce((pv,cv)=>{ return pv + cv},0)/1000))
}
test();

HTML:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<p></p>
<div></div>

Il n'y a pas de doute que c'est plus rapide, la principale question reste cependant sans réponse - pourquoi? 😉

InformationsquelleAutor Matas Vaitkevicius

Vous devez vous connecter pour publier un commentaire.