Actuellement, je crée une application Web basée sur le Web (= JavaScript) qui utilise beaucoup de "points" (= petits vecteurs de taille fixe). Il y a essentiellement deux moyens évidents de les représenter: et alors traduire mon point un peu ressemblerait à: Les deux sont faciles à gérer à partir d'un point de vue du programmeur (la variante d'objet est un peu plus lisible, d'autant plus que je traite principalement des données 2D, rarement avec 3D et à peine avec 4D - Mais jamais plus. Ça va toujours s'intégrer dans x, y, z et w) mais ma question est maintenant: Mes navigateurs cible sont Firefox et les webkit (chrome, safari), mais cela ne ferait pas mal d'avoir une excellente expérience (= rapide) sous IE et Opera ...
Quelle est la voie la plus efficace de la perspective de la langue - théoriquement et dans de vraies implémentations?
Quelles sont les exigences de la mémoire?
Quels sont les coûts de configuration d'un tableau vs objet?
...
3 Réponses :
My Hunch est que les matrices vous donneront une meilleure performance. (!)
Cela dit, le code est déjà significativement moins lisible dans votre exemple que dans votre exemple d'objet. Les gains sont probablement légers, alors je vous suggère de faire des analyses de base et de la serviette de base pour mettre un nombre réel sur le compromis.
pour commencer, vous pourriez
tableaux
- Accédez à leurs champs 1 million de fois.
- Répétez avec
Objets et comparez.
(!) - Un bon exemple de pourquoi l'analyse comparative est si utile: les tableaux sont en effet meilleure pour la création, mais les objets sont meilleurs pour l'accès, ce qui pourrait être très important (selon vos besoins). Galambalazs a écrit un excellent test pour cette affaire: http://jsperf.com/Object-vs-array
Vous avez raison que seul un point de repère donnera "la réponse" - mais JavaScript a actuellement un élan majeur pour obtenir des implémentations plus rapides et encore plus rapides, je crains que la décision de conception basée sur des points de repère actuels soit bientôt obsolète ...
Vous avez raison. En fait, sauf si je suis en train de mettre en œuvre quelque chose avec des besoins de performance spéciaux (ou la magnitude des forces de commerce ma main), je toujours favorise l'épargne le temps de développeur par rapport au temps de la machine, en particulier sur les prototypes. En tant que tout développement logiciel, encapsulez bien et ne vous répétez pas vous-même, le refactoring peut donc se produire plus tard sans trop de douleur.
Avec Google V8, je pense que la version de la classe sera aussi rapide que le code C ++ compilé.
Les matrices sont plus rapides pour créer, mais si vous envisagez l'heure d'accès, c'est l'inverse. Notez également que la forme constructeur est rapide à créer et à accéder. Il a le meilleur des deux mots dans les implémentations modernes navigateurs testés: chrome 10, Firefox 3.6, Firefox Beta 4.0b9, IE 9 Aperçu 7, Opera 11 nouveau vecteur (x, y) - [ test ]
Le tableau et l'accès à l'objet ne font presque aucune différence dans le chrome 8. Mais la création de tableau est beaucoup plus rapide.
hmm ... Je suppose que l'accès plus lent pour les valeurs de tableau est la coercition d'un numéro à une chaîne. N'oubliez pas que les matrices sont des objets , afin que les index de tableau sont encore encore des propriétés sur un objet. arr [0] et arr ["0"] est fonctionnellement identique, mais le premier devrait être légèrement plus lentement en théorie.
@Felix - Oui, mais il a dit qu'il veut le meilleur pour FF et chrome. Et il y a 20% de différence dans la FF4.0B9 pour moi (et même plus grande pour 3.6).
Comme j'ai écrit sur la réponse ci-dessus, je crains de baser ma décision uniquement sur les résultats de référence. Donc le arr [0] vs. arr [0 '] peut être totalement non pertinent lors de la mise en œuvre basée sur JIT pouvant optimiser ce constrateur.
@Chris - Vous avez la possibilité d'optimiser les implémentations n'existant même pas. C'est ton appel. :) Décidez simplement si vous souhaitez une expérience utilisateur rapide pour les personnes vivant aujourd'hui ou peut-être 10 ans à partir de maintenant. :)
Maintenant, j'ai étendu le test par la cordon de cordes: jsperf.com/Object-vs-array/ 2 Il est facile de voir, qu'il n'y a pas de réponse correcte par les implémentations actuelles de JavaScript. Ce que nous pouvons dire, c'est que seul un "vieux" a (légèrement) des temps d'accès plus rapides en utilisant des chaînes - les autres navigateurs souffrent de manière significative. En dehors de cela, c'est indécis ... Quelqu'un peut-il savoir sur la consommation de mémoire? (Y a-t-il même un moyen de le mesurer, comme la taille C ()?)
@Chris - Je ne veux pas sonner trop offensant, mais vous semblez manquer de bon sens dans ce cas. :) "C'est facile à voir, qu'il n'y a pas de réponse correcte" - ce que je vois, c'est de ne pas utiliser de chaînes, puis il est rapide partout partout. Pensez-y...
@Agalambalazs: Vous avez raison que cela a atteint le point où nous pouvons nous arrêter et dire que le côté de la mise en œuvre n'a pas d'importance - même si cela nous donnerait une réponse, qu'il ne s'agit pas - et seul le côté du développeur compte. La seule "réponse" manquante est la consommation de mémoire. En utilisant le profileur de chrome et en stockant un million de matrices 2D et de vecteurs, je vois une légère différence: les matrices ont besoin de 80 Mo, les objets 38 Mo.
@Chris: Je viens de se rendre compte, il est de sens que arr ['0'] serait plus lent - car il y a aussi un Tostring (TOUINT32 ('0') === '0' effectué en raison de la nature particulière des objets de tableau. Peut-être que Firefox a déjà des optimisations en place pour éviter ce type de redondance.
@Andy: Le coût de la découverte de sa propriété indexée est effectué est l'analyse du temps, il n'ya donc aucun coût de temps d'exécution (qui est tous des tests JSPERF). Je suis méfiant cependant que le test d'accès est biais vers des objets par le coût de la définition des propriétés et non de l'accès lui-même.
@Andy: Bien sûr, il est évident que Firefox 3.6 ne le fait pas à l'analyse, mais d'autres implémentations font.
@gSnedDers: Cela semble improbable - une implémentation ne peut pas connaître la valeur d'une variable à l'heure d'analyse et ne peut donc pas connaître le résultat de Tostring (TOUINT32 (var)) .
@Andy: Vous ne pouvez pas le faire dans le cas où il s'agit d'une variable, mais ARR ['0'] est une constante, connue à l'analyse du temps, de sorte que ToString (TOUINT32 ('0')) peut être déterminé à l'analyse temps.
@gsnetdders: Oh, je vois ce que tu veux dire. Je l'ai écrit comme ça pour simplifier ce que je disais, mais j'avais l'intention d'appliquer plus généralement à toute valeur ou variable inconnue à l'heure d'analyse.
Merci pour toutes les réponses et l'entrée. Très intéressant étaient les résultats du test écrit par Galamalazs: http://jsperf.com/Object-vs -Array / 2
Prendre tous les aspects ensemble Nous obtiendrons:
Ainsi, à la fin, les deux options sont sensibles et seule la lisibilité du code prendra la décision!
S'il s'agit principalement de stocker des données avec un travail trivial (comme dans mon projet actuel), l'objet est la voie à suivre. Un Dans la plupart des applications orientées mathématiquement avec des mathématiques vectorielles telles que les transformations de coordonnées (surtout en 3D), le meilleur moyen serait le cas de la matrice, car les choses comme les multiplications matricielles semblaient plus originales du développeur et montrent son intention. souris.x et souris.y montre trivialement le développeur intention.
Mon sentiment dit que les objets consomment moins de mémoire: un objet est la structure de données de base en JS. Les tableaux sont encaissés sur des objets et fournissent des méthodes supplémentaires. Mais la différence est probablement négligeable.
Des méthodes supplémentaires sont stockées sur
array.pototype . Aucun tableau ne les détient directement.