Reprise du message précédent :

peut-être que si je veux que google me rappelle, je dois lui dire où je suis ?

Y U ASK GOOGLE CALL U

Yo, juste un petite question.
 
Je voulais changer la couleur d'un lien survolé dans une class spécifique.
 

 
c'est pas censé marcher si je fais ça  

 
chez moi ça marche

Ouép c'est bien ce que je pensais, ben du coup j'vois pas  

Also .texte:hover

 
c'est pas une connerie genre le contenant qui te bouffe le hover? je met toujours mes hover sur les li, perso.

Chez moi (FF 2 ) ça ne marche pas.
 
Par contre .texte a:hover {color:#00ffff;} oui.

 
ne pas upgrader ie, je conçois, mais ya des gens qui trainent sur des vieux ff?

 
 
Oui c'est ça, ça fonctionne. merci  

 
mais c'est pas le même chemin, si je ne me méprend

Oui erreur de ma part, la class était pas sur le lien spécifiquement.

on a trouvé LE client de koskoz

http://jsperf.com/iterations-tests

Un foreach basique implémenté en pur js sur base de for( ;; ) est plus rapide que Array.forEach

 
PQ

Attends what?  
 

 
OK, ça JIT mais quand même

C'est pas à ce point chez moi (j'ai pas d/l FF5), mais avec Webkit trunk (nitro toussa), j'ai 20k et 40k entre forEach et each (28 et 58 avec Chrome 12).

Bon après forEach est une méthode générique à laquelle tu peux filer des trucs qui sont pas des arrays, et tu peux lui filer un this pour binder dans la scope toussa, mais quand même

Ah oui j'ai oublié de préciser que l'itération C-style elle va un peu vite, dans chrome

Hé mais, ton code, il marche pas, arnaqueur
Je capte toujours pas que le native each soit si lent. (sous FF5)

Edith : Fais un test avec apply, ça devrait ralentir ton each manuel.

   
 
J'ai fait une connerie?
 
edit: ah oui je viens de voir, effectivement c'est tout de suite moins impressionnant quand on se plante pas sur le nom d'une propriété
 
Mais c'est cool, ça veut dire que les itérateurs haut niveau sont encore plus compétitifs

Ça va le défoncer complètement, mais je vois pas pourquoi je ferais ça
 
edit: http://jsperf.com/iterations-tests/3 ça marche tous les paramètres fournis par Array.prototype.forEach, mais pas le this, en appel direct & call & apply, étrangement les perfs entre native et les autres sont les mêmes là
 
edit2: http://jsperf.com/iterations-tests/5 holy mother of caca, mettre 3 params au lieu d'1 ça divise les perfs par 2 sous safari
 
Bon, donc après avoir fixé le test C-style, sous Webkit trunk et Chrome 12, OSX:

• Array.prototype.forEach est 3~5 fois plus lent qu'une itération c-style (3 sous Safari, presque 5 sous chrome)
• Sous Safari, apply et call sont ~20% plus lents que l'appel direct (c'est beaucoup, ce n'est pas trop)
• Pareil sous Chrome entre call et appel direct
• Par contre apply divise les perfs par 3 par rapport à l'appel direct
• Passer le foreach manuel de 1 à 3 paramètres pas utilisés divise les perfs par 2 sous Safari, et les diminue de 30% sous chrome
• Les perfs remontent beaucoup si le callback prend les 3 paramètres et en ignore 2, plutôt que de ne prendre qu'un paramètre. Apparemment, les moteurs aiment pas du tout les mismatches, comparer tests 3 (3 params envoyés, 1 reçu) 5 (1 param envoyé, 1 reçu) et 6 (3 params envoyés, 3 reçus). Sous Safari, entre 1 et 3 params les perfs sont identiques tant que ça matche, sous Chrome l'appel direct est identique, call et apply sont un poil plus lents en 3 params.
• ça fait pas de différence pour le forEach natif, qui se prend une branlée par tous les foreaches manuels sauf .apply sous Chrome

=> même si on ignore les paramètres, toujours matcher le nombre de paramètres envoyés par l'appellant aux nombre de paramètres reçus par l'appelé, dans le code JS  
=> direct >> call >>>> apply, paske Chrome/V8 aime pas du tout du tout apply  
=> les jits se sont tellement améliorés qu'un foreach manuel peut être plus rapide qu'un foreach natif  
=> ça se rapporte pas nécessairement aux autres méthodes natives (genre filter/map) à cause de l'object churn (besoin de créer l'array de sortie toussa)
=> et accessoirement, les gens qui utilisent for...in sur les arrays faut les buter, non seulement c'est faux mais c'est lent. Si encore ça merdait rapidement ce serait excusable

Ouais bon, pour utiliser forEach dans un truc perf sensitive faut vraiment être con
Le apply c'est super violent par contre

Tu sais pas toujours ce qui va être sensible
 
Et puis bon les perfs de foreach sont quand même très acceptables

Sous Chrome mais pas sous Safari
 
Accessoirement j'ai ajouté des conclusions, et le mismatch de params ça fait super mal en fait

C'est marrant de voir que CHrome est beaucoup plus rapides sur certaines fonctions que Firefox et inversement.

vous avez un exemple d’utilisation où vous comptez les µs?

 
T'as pas vu les benchs juste au dessus ?

Attends c'est quoi a.index ?

Le HTML5 Boilerplate utilisera maintenant le normalize.css au lieu du reset.css + base.css
 
https://raw.github.com/necolas/norm [...] malize.css

Ah bien

C'est rien, d'où les perfs

Une erreur/typo, corrigé dans le test 5 (mais re-pêté dans le test 6, qui est forké du test 3), ça impacte que le test for classique, et le résultat est surtout de rendre les autres solutions vachement plus compétitives

 
c'est vrai que c'est particulièrement concret et utile comme application un bench, d'ailleurs si j'ai une cg à 300 boules c'est juste pour peter du score à 3dm

 
T'es idiot, c'est ça ?

 
c'est fort possible mais ça ne répond pas à la question;
 
dans quel cas est-il utile d'avoir 50 000 000 opé par secondes plutot que 10 000?

et l'inverse  ?  
si le code est aussi lisible, pas plus complexe, autant prendre la solution a plus rapide

Parce que les applications Web deviennent de plus en plus complexes et manipulent de plus en plus de données ?
A l'inverse certains traitements lourds qui ne actuellement pas possibles en JS pur parce que trop lents pourraient être envisagés si le langage était plus rapide et donc déporté certains traitements serveurs vers le client.
 
( après c'est sur que tout ça dépend pas uniquement de la vitesse d'un for ... each )

J'ajoute une bordure sur un input de type "search" avec appearance à none, sinon c'est moche sous webkit).
J'ai l'impression (c'est plus une constatation d'ailleurs) que Firefox ajoute la bordure en dehors du height que j'ai fixé alors que webkit le rajoute dans celui-ci

Étant donné qu'on touche à de l'UI, la réactivité de l'interface est un élément déterminant.
La performance d'éléments de base du langage est un point à surveiller parce que ça fait la différence entre "cette fonctionnalité est utilisable" et "je balance l'écran par la fenêtre".

Et désolé pour le "t'es idiot", c'était inapproprié. Fatigué, journée de chie, tout ça.

 
si c'est aussi lisible et pas plus complexe, évidemment mais quand je me trimballe des tableaux imbriqués, foreach est quand meme plus sympa que de se faire chier à réinventer la roue