Pourquoi la mutation de la [[prototype]] d'un objet mauvais pour la performance?

Du MDN docs pour la standard setPrototypeOf function ainsi que la non-standard __proto__ de la propriété:

La mutation de la [[Prototype]] d'un objet, peu importe comment cela est accompli, il est fortement déconseillé, car il est très lent et inévitablement ralentit l'exécution subséquente moderne implémentations de JavaScript.

À l'aide de Function.prototype pour ajouter des propriétés est la façon d'ajouter des fonctions de membre de classes javascript. Alors, comme le montre l'exemple suivant: 

function Foo(){}
function bar(){}

var foo = new Foo();

//This is bad: 
//foo.__proto__.bar = bar;

//But this is okay
Foo.prototype.bar = bar;

//Both cause this to be true: 
console.log(foo.__proto__.bar == bar); //true

Pourquoi est foo.__proto__.bar = bar; mauvais? Si son mal n'est pas Foo.prototype.bar = bar; tout aussi mauvais?

Alors pourquoi cette mise en garde: il est très lent et inévitablement ralentit l'exécution subséquente moderne implémentations JavaScript. Sûrement Foo.prototype.bar = bar; n'est pas si mauvais que ça.

Mise à jour peut-être par la mutation qu'ils voulaient dire d'une réaffectation. Voir accepté de répondre.

  • __proto__ est obsolète non-standard de la propriété. ainsi que sur la manière, il serait agréable de voir les réponses que l'adresse de performances de la question directement: Pourquoi est-il "..très lente et, inévitablement, ralentit l'exécution subséquente moderne implémentations JavaScript"?
  • merci. C'était mon intention. Mise à jour de question pour être plus explicit en mentionnant la nouvelle façon standard.
  • Je ne peux pas trouver la réponse, je veux faire référence, mais autant que je me souvienne de modifier le prototype nécessiterait la js moteur de jeter tous les code natif créé par le JIT-compilateur pour ces objets, comme les propriétés ne correspondent plus, ce qui ralentit tout.
  • d'accord. C'est pourquoi je me demande pourquoi foo.__proto__.bar = bar; est mauvais.
  • J'imagine qu'ils ont tous deux le même problème. Il semble que la JS moteur aurait besoin de "vider" toute mise en cache de la propriété des résolutions ou d'autres compilé/intermédiaire IL pour tous enchaînés (dérivée) des objets.
  • Je suppose qu'il doit dire la mutation après avoir instances créées est mauvais. Deux de ces méthodes pourraient être tout aussi mauvais et Alex réponse s'appliquent.
  • Peut-être. Mais je ne suis pas d'accord avec cette réponse, car il me semble jupe toutes les questions relatives à l'explicite mutation (on peut muter sans __proto__, comme indiqué) et implique qu'il n'y a pas de telles optimisations en cours (qui auraient un impact sur les performances wrt. les mutations non-nulle).
  • J'ai trouvé la question et la réponse correspondante que je recherche: dois-je mettre les valeurs par défaut des attributs sur le prototype pour économiser de l'espace? bien que pas entièrement lié je pense que c'est une des raisons pour lesquelles vous ne devriez pas le faire.

InformationsquelleAutor basarat | 2014-05-22
  1. 55
    //This is bad: 
//foo.__proto__.bar = bar;

//But this is okay
Foo.prototype.bar = bar;

    Pas. Les deux font la même chose (comme foo.__proto__ === Foo.prototype), et les deux sont très bien. Ils sont juste la création d'un bar bien sur la Object.getPrototypeOf(foo) objet.

    Ce que la déclaration se réfère à l'est de l'affectation à la __proto__ de la propriété elle-même:

    function Employee() {}
var fred = new Employee();

//Assign a new object to __proto__
fred.__proto__ = Object.prototype;
//Or equally:
Object.setPrototypeOf(fred, Object.prototype);

    L'avertissement au de l'Objet.prototype de la page va plus dans le détail:

    La mutation de la [[Prototype]] d'un objet est, par la nature de la façon dont moderne moteurs JavaScript optimiser l'accès à la propriété, une très lente opération

    Ils simplement que modifier le prototype de la chaîne d' de l'existence d'un objet tue optimisations. Au lieu de cela, vous êtes censé créer un nouvel objet avec un autre prototype de la chaîne via Object.create().

    Je ne pouvais pas trouver une référence explicite, mais si l'on considère la façon dont V8 cachés de classes sont mis en œuvre, nous pouvons voir ce qui pourrait aller sur ici. Lors de la modification de la chaîne de prototype d'un objet, son type interne des changements - il ne se contente pas de devenir une sous-classe comme lors de l'ajout d'une propriété, mais est complètement inversés. Cela signifie que tous les biens de recherche d'optimisations sont vidées, et précompilés code devront être jetés. Ou simplement, il revient à la non optimisation de code.

    Quelques citations notables:

    • Brendan Eich (vous savez de lui) a dit

      Inscriptible __proto__ est un géant de la douleur à mettre en œuvre (doit sérialiser cycle-à vérifier) et il crée toutes sortes de type de confusion dangers.

    • Brian Hackett (Mozilla) a dit:

      Permettant de scripts pour muter le prototype de pratiquement n'importe quel objet il est plus difficile de raisonner sur le comportement d'un script et fait VM, JIT, et l'analyse de la mise en œuvre plus complexe et buggier. L'inférence de Type a eu plusieurs bugs dus à mutable __proto__ et ne peut pas maintenir plusieurs souhaitable invariants en raison de cette fonction (c'est à dire de type jeux de contenir tous les objets de type qui peut réaliser pour un var/propriété " et "JSFunctions ont des types qui sont aussi des fonctions').

    • Jeff Walden a dit:

      Prototype de mutation après la création, avec ses performances insuffisantes de la déstabilisation, et l'impact sur les procurations et les [[SetInheritance]]

    • Erik Corry (Google) a dit:

      Je n'attends pas de grands gains de performance de faire des proto non-overwritable. Dans la non optimisation de code, vous devez vérifier la chaîne de prototype dans le cas où le prototype des objets (pas de leur identité) ont été modifiés. Dans le cas d'un code optimisé, vous pouvez revenir à nonoptimized code, si quelqu'un écrit à proto. Donc il ne serait pas beaucoup de différence, au moins dans un moteur V8 de Vilebrequin.

    • Éric Faust (Mozilla) a dit

      Lorsque vous définissez __proto__, non seulement sont vous ruiner toutes les chances que vous pourriez avoir eu pour de futures optimisations de l'Ion sur cet objet, mais vous pouvez aussi forcer le moteur pour aller ramper à toutes les autres pièces de l'inférence de type (informations sur les valeurs de retour de fonction, ou des valeurs de propriété, peut-être) qui pensent qu'ils savent à propos de cet objet et de leur dire de ne pas faire de nombreuses hypothèses, ce qui implique de nouvelles deoptimization et peut-être l'invalidation de l'existant jitcode.

      Modifier le prototype d'un objet dans le milieu de l'exécution est vraiment un méchant de masse, et le seul moyen que nous avons pour éviter de se tromper, c'est jouer la sécurité, mais la sécurité est lente.

    • Je pense que nous avons tous lu la page OP liés. Ce est ces certaines optimisations?
    • Selon cette par la mutation ils veulent dire réaffectation. Dans ce cas, à l'aide de fred = Object.create(Object.prototype) devrait être tout aussi mauvais. Mais ils specifially dire son bon : Instead, create the object with the desired [[Prototype]] using Object.create.. Je pense que vous avez raison cependant. Ils ont éventuellement optimisé Object.create.
    • Il y a une importante différence de performance entre l'objet.créer et proto : jsperf.com/proto-vs-object-create2 Merci pour votre temps
    • Je me suis abstenu de l'écriture d'un jsperf, car celles-ci sont difficiles à écrire et vous ne savez pas exactement leur test (ou si ce que vous testez est pertinente dans le code réel, ou vous avez obtenu un facilement optimisable un). L'affaire est lié a quelques bons essais dans les dernières révisions. Pour ton test, j'ai mise à jour avec une cible statique prototype de nouveaux objets, qui montre la différence encore mieux.
    • est uber optimisé sous Mozilla, mais échoue lamentablement en V8. lors de la mise en Node.js la programmation, l' __proto__ est généralement une meilleure appel, performance sage. Express.js utilise __proto__ en raison des gains de performance à l'encontre de l'Objet.créer
    • Lisez également le premier alinéa de l' mail.mozilla.org/pipermail/es-discuss/2010-April/010917.html
    • Super réponse, il m'a fait mieux comprendre l'ensemble du prototype en question et en sachant que de simplement ajouter des méthodes pour le prototype est très bien est une belle solution dans la plupart des cas. Signifie-t-il, je peux aussi ne delete MyObject.__proto__['method']; sans aucun problème?
    • Non, delete a ses propres problèmes.
    • Pour info, le lien vers la v8 cachés de classes de mise en oeuvre est cassé
    • Merci, fixe
    • Auriez-vous tout de savoir si la performance est également impacté si Object.setPrototypeOf() est utilisé tout de suite après la création de l'objet et de la chaîne de prototype n'est pas touché par la suite? La principale raison de la demande, c'est que Object.create() ne peut pas être utilisé pour l'initialisation d'un objet avec des méthodes faisant usage de la super mot-clé. En d'autres termes, la suite sera bien?: const parent = { method() {} }; const child = { method() { super.method() } }; Object.setPrototypeOf(child, parent);
    • Alors que je n'en ai aucune idée, je n'en attendent pas de problèmes et de penser à la const child = Object.setPrototypeOf({ method() { super.method() } }, parent) modèle est très bien. Les moteurs doivent être en mesure d'optimiser cela, et si ils ne le font pas, je voudrais déposer une demande de fonctionnalité. Comme vous le dites, c'est le seul moyen de rendre les méthodes de travail dans les littéraux d'objet, aussi il est nécessaire pour des tableaux ou des fonctions personnalisées prototype de chaînes. Viens de l'utiliser dans ces cas.
    • Cela dit, je ne vais pas éditer ma réponse à recommander l'utilisation de Object.setPrototypeOf. Aussi, vous pourriez rencontrer des problèmes de performance dans certains moteurs, de sorte que vous devrait référence attentivement, si vous vous souciez de lui. Ensuite, je veux le regarder dans l'aide de class syntaxe comme une alternative, les moteurs de soins pour optimiser qui mieux depuis que c'est de plus en plus populaire.

    InformationsquelleAutor Bergi
  2. 2

    __proto__/setPrototypeOf ne sont pas les mêmes que l'affectation de l'objet prototype. Par exemple, lorsque vous avez une fonction/objet avec des membres qui lui sont assignées:

    function Constructor(){
    if (!(this instanceof Constructor)){
        return new Constructor();
    } 
}

Constructor.data = 1;

Constructor.staticMember = function(){
    return this.data;
}

Constructor.prototype.instanceMember = function(){
    return this.constructor.data;
}

Constructor.prototype.constructor = Constructor;

//By doing the following, you are almost doing the same as assigning to 
//__proto__, but actually not the same :P
var newObj = Object.create(Constructor);//BUT newObj is now an object and not a 
//function like !!!Constructor!!! 
//(typeof newObj === 'object' !== typeof Constructor === 'function'), and you 
//lost the ability to instantiate it, "new newObj" returns not a constructor, 
//you have .prototype but can't use it. 
newObj = Object.create(Constructor.prototype); 
//now you have access to newObj.instanceMember 
//but staticMember is not available. newObj instanceof Constructor is true

//we can use a function like the original constructor to retain 
//functionality, like self invoking it newObj(), accessing static 
//members, etc, which isn't possible with Object.create
var newObj = function(){
    if (!(this instanceof newObj)){   
        return new newObj();
    }
}; 
newObj.__proto__ = Constructor;
newObj.prototype.__proto__ = Constructor.prototype;
newObj.data = 2;

(new newObj()).instanceMember(); //2
newObj().instanceMember(); //2
newObj.staticMember(); //2
newObj() instanceof Constructor; //is true
Constructor.staticMember(); //1

    Tout le monde semble être en se concentrant uniquement sur le prototype, et d'oublier que les fonctions peuvent avoir des membres qui lui sont assignées et instancié après la mutation. Il n'y a actuellement pas d'autre moyen de le faire sans l'aide de __proto__/setPrototypeOf. À peine toute personne d'utiliser un constructeur sans la possibilité d'hériter d'un parent fonction constructeur, et Object.create ne parvient pas à servir.

    Et en plus, c'est deux Object.create appels, qui, à l'heure actuelle, est impie lent en V8 (à la fois le navigateur et le Nœud), ce qui rend __proto__ un choix plus viable

    InformationsquelleAutor pocesar
  3. 1

    Oui .prototype= est tout aussi mauvais, d'où l'expression "peu importe comment il est accompli". prototype est un pseudo-objet pour l'extension de la fonctionnalité au niveau de la classe. Sa nature dynamique ralentit l'exécution du script. Ajout d'une fonction de niveau de l'instance, d'autre part, subit beaucoup moins de frais généraux.

    • Adding a function on the instance level...incurs far less overhead. - jusqu'à ce que vous avez de nombreux cas.
    • Plus le contexte est nécessaire. De ma compréhension de liens à des ressources qu'il se rapporte spécifiquement à la mutation de la [prototype] objet. En tant que tel, l'affectation à Fn.prototype n'est pas "juste comme mauvais" parce que c'est copié sur create. (La question porte sur la mutation le prototype de l'objet.)
    InformationsquelleAutor Schien
  4. 0

    Ici est un repère à l'aide de nœud v6.11.1

    NormalClass: Une classe normale, avec le prototype non édité

    PrototypeEdited: Une classe avec le prototype modifié (le test() fonction est ajoutée)

    PrototypeReference: Une classe avec le prototype de la fonction test() qui referer à une variable externe

    Résultats :

    NormalClass x 71,743,432 ops/sec ±2.28% (75 runs sampled)
PrototypeEdited x 73,433,637 ops/sec ±1.44% (75 runs sampled)
PrototypeReference x 71,337,583 ops/sec ±1.91% (74 runs sampled)

    Comme vous pouvez le voir, le prototype édité classe est un moyen plus rapide de la classe normale. Le prototype qui a une variable qui se réfèrent à une externe est le plus lent, mais c'est une façon intéressante de modifier les prototypes avec déjà instantied variable

    Source : 

    const Benchmark = require('benchmark')
class NormalClass {
  constructor () {
    this.cat = 0
  }
  test () {
    this.cat = 1
  }
}
class PrototypeEdited {
  constructor () {
    this.cat = 0
  }
}
PrototypeEdited.prototype.test = function () {
  this.cat = 0
}

class PrototypeReference {
  constructor () {
    this.cat = 0
  }
}
var catRef = 5
PrototypeReference.prototype.test = function () {
  this.cat = catRef
}
function normalClass () {
  var tmp = new NormalClass()
  tmp.test()
}
function prototypeEdited () {
  var tmp = new PrototypeEdited()
  tmp.test()
}
function prototypeReference () {
  var tmp = new PrototypeReference()
  tmp.test()
}
var suite = new Benchmark.Suite()
suite.add('NormalClass', normalClass)
.add('PrototypeEdited', prototypeEdited)
.add('PrototypeReference', prototypeReference)
.on('cycle', function (event) {
  console.log(String(event.target))
})
.run()
    • Aucun de ces exemples impliquent une modification de la [[prototype]] slot de n'importe quel objet (par écrit à .__proto__ ou en appelant Object.setProtottypeOf(), de sorte que l'indice de référence, bien qu'intéressante, n'est pas pertinente à la question posée.
    InformationsquelleAutor Simon Et la famille