Question

Venant du C/C++, la disposition de la mémoire des objets en ce qui concerne la réduction des échecs de cache est quelque chose de crucial, en particulier lorsque l'on travaille sur des consoles.La conception orientée données est souvent privilégiée par rapport à la conception orientée objet, afin de permettre de conserver en mémoire les objets associés proches les uns des autres (en particulier dans les domaines critiques en termes de performances).

Récemment, j'ai fait du développement Javascript et je me demande quel est le consensus général au sein de la communauté Javascript.

Avec mon expérience limitée en Javascript, j'ai souvent été surpris de voir des résultats complètement inattendus lors du profilage.La disposition de la mémoire interne et la mise en œuvre des objets/structures Javascript varient tellement d'un navigateur à l'autre que je me demande si cela vaut la peine de tenter d'optimiser.

J'ai créé un cas de test simple (http://jsperf.com/object-vs-data) sur jsPerf pour comparer les performances des deux méthodes, et bien qu'il affiche des gains de performances sur Chrome, il n'y a pas d'accélération notable sur Safari.

En Javascript, dois-je même me préoccuper de la disposition de la mémoire des objets ?Ou s'agit-il plutôt d'une chose du type « implémenter dans un sens, puis optimiser si nécessaire » ?

Cette deuxième option semble un peu inutile (en termes de temps de développement), surtout s’il existe de bonnes directives à suivre.

Merci~

Information supplémentaire:C’est essentiellement ainsi que j’implémenterais les deux approches en Javascript.Le cas de test jsPerf ci-dessus est implémenté comme ceci.

var objectOriented = [
    { foo: 1, bar: 2 },
    { foo: 3, bar: 4 }
];

var dataOriented = {
    foos: [1, 3],
    bars: [2, 4]
};

// Object-oriented access:
var a = objectOriented[0].bar;

// Data-oriented access:
var b = dataOriented.bars[0];
Était-ce utile?

La solution

Vous travaillez à partir d'une hypothèse fondamentale que des objets dans JavaScript fonctionne comme ils le font en C ++. Ils ne le font pas.

en C ++, l'objectif principal d'un type est d'agir comme une "lentille" sur un morceau de mémoire. La mise en page de classe définit directement le contenu de la mémoire que l'objet décrit, de manière bien définie. Les tableaux C / C ++ nécessitent spécifiquement une disposition linéaire et continue de types homogènes.

En JavaScript, un objet est une collection de paires nom / valeur. Un tableau est juste un objet avec une propriété spéciale "longueur". Notez qu'il n'y a pas de description ou de définition de la mise en page de la mémoire ici. Il n'y a rien d'arrêter d'interprète JavaScript à partir de la mise en œuvre de tableaux en tant que table de hachage plutôt qu'à une partie de la mémoire linéaire; En fait, je suis sûr qu'ils sont des implémentations JS qui font exactement cela.

Les implémentations JavaScript sont libres de définir la mémoire mais elles veulent, et il n'y a pas de correspondance entre rien que vous ne faites à la source et ce qui finit réellement dans la machine.

En outre, les matrices JavaScript sont hétérogènes, pas homogènes. C'est-à-dire en supposant qu'il a été aménagé dans une mémoire contiguë, votre type équivalent en C serait JSOBJECT **, pas INT ** (ou float ** ou autre). Un tableau JS est une collection de références aux données stockées ailleurs, alors même si les références figuraient dans votre ligne de cache, vos données ne seront pas.

Donc, en résumé - ce genre de pensée ne vous gagnera que de la douleur. JavaScript est une langue de niveau beaucoup plus élevée que c ++ et une partie de cela donne le contrôle que vous avez utilisé. Ce type d'optimisation de bas niveau si possible sera effectué par l'interprète. Concentrez-vous sur le code d'écriture avec des algorithmes efficaces qui expriment naturellement votre solution; C'est assez fort que c'est. : -)

Autres conseils

D'accord.J'ai manipulé quelques chiffres et cas de test.

Tout d'abord, j'ai créé ce cas de test http://jsperf.com/object-vs-array-creation-for-soDans ce cas, créer Object est beaucoup plus vite puis créer un Array

Deuxièmement, j'ai créé ce cas de test http://jsperf.com/accessing-speedEn cela, il n’y avait pratiquement aucune différence entre eux.

Donc, ce que je déduis de ce profil, c'est que l'utilisation d'objets plus que de tableaux sera plus rapide si le projet est vraiment énorme..car, dès le premier cas, il est clair que la création d'objets est plus rapide que la création de tableaux.

Mais..

Javascript est un langage hautement développé et performant et vous ne devriez pas vous inquiéter de telles micro-optimisations.Tout ce que vous devez vous concentrer, c'est sur le sémantique.Vous devez choisir la structure qui décrit le mieux votre intention.

Test dans Chrome 36.0.1985.125 sur Windows NT 6.3

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top