¿Es mejor tener un objeto grande en JavaScript o muchos más pequeños?

Question

Escribo una lib de JS que lee juegos de ajedrez para convertirlos en juegos re jugables, en una sola página web puede haber muchos juegos (uno en su propio div), lo que me pregunto es - pensando en el rendimiento - si es mejor tener un objeto grande que contenga todos los movimientos de todos los juegos o muchos objetos más pequeños, cada uno almacenando los movimientos de un juego.

Me doy cuenta de que este es quizás un pequeño punto en todo el proceso de optimización, pero es el que quiero abordar ahora.

Answer 1

Donald Knuth: "Debemos olvidarnos de pequeñas eficiencias, por ejemplo alrededor del 97% del tiempo: la optimización prematura es la raíz de todo mal"

de inicio mediante el diseño de un modelo de datos para su juego que es correcto y natural desde un punto de vista de modelado de dominio.

Cree el software.

Luego, cuando se encuentre en una etapa de desarrollo que analice el rendimiento tiene sentido, trabaje en algunos entornos de bajo rendimiento en los que le gustaría que funcione su juego, y pruebe en ellos.

Probablemente encontrará que no tiene problemas, como otros han indicado en las respuestas a esta pregunta.

Si encuentra un problema, haga un perfil de su código y descubra la causa. Optimiza el código que necesitas. Incluso si encuentra un problema de rendimiento, es poco probable que sea causado por su modelo de datos, siempre que lo haya diseñado bien.

Si el modelo de datos es realmente un problema de rendimiento, solo entonces debe comprometer su diseño inicial solo en la medida necesaria para obtener el rendimiento que necesita, documentando los compromisos que ha realizado y por qué tuvo que .

Answer 2

No se preocupe innecesariamente por el rendimiento. Diseñarlo de una manera que parece natural. Obviamente, no desea poner todas las jugadas de todos los juegos en un solo objeto, que derrota el propósito del diseño orientado a objetos. Ve con la segunda opción y ten un objeto para cada juego. Es muy poco probable que tenga problemas a menos que esté cargando varios miles de juegos en una sola página.

Answer 3

Creo que esta pregunta es mucho más sobre el diseño del software que sobre el rendimiento. Pero me alegro de que lo estés abordando ahora, evitando refactorizar más tarde.

Creo que debería pensar en cada juego como una instancia (div) de un objeto ChessGame. Esto facilitará gran parte del resto del desarrollo, como la creación de libs y funciones personalizadas para manejar el juego, también tendrás la posibilidad de enhebrar cada juego (google para "trabajadores web"), aumentando el rendimiento general.

Answer 4

Los objetos pequeños son la opción preferible en mis ojos.

• Desde una perspectiva de la ingeniería de software, es mucho mejor tener un diseño más modular con pequeñas, componibles objetos en lugar de un objeto monolítico. En lugar de tener un objeto por juego, incluso representaría cada movimiento como un objeto.
• Motores JS recientes como V8 intentan construir objetos similares a estructuras a partir de definiciones de "clase". Esto ocurre entre bastidores para un rápido acceso a la propiedad. Google explica esto en the design of V8. Básicamente, si tiene varias instancias pequeñas de la misma clase que es más o menos estática (es decir, cada instancia de la clase tiene las mismas propiedades), V8 puede optimizar para este caso.

Answer 5

La mejor forma de aprovechar los objetos es utilizar el patrón de prototipos en JavaScript. Esto significa que comparte datos con objetos, en lugar de ser mezquino y decir "¡Eso es mío!".

Este patrón está por todas partes en las bibliotecas de JavaScript. Se ve algo como esto:

var Template = { 
    extend: function() { 
    var F = function() {}; 
    F.prototype = this.prototype; 
    var instance = new F(); 
    instance.mixin.apply(instance, arguments); 

    return instance; 
    }, 

    mixin: function (mixins) { 
    for (var i = 0, len = arguments.length; i < len; i++) { 
     for (var k in arguments[i]) if (arguments[i].hasOwnProperty(k)) { 
     this[k] = arguments[i][k]; 
     } 
    } 

    return this; 
    } 
}; 

Esta clase mágica compartirá datos a través de cadenas de herencia, y hacer que su modelo de objetos más simple . ¡Nada es una clase, todo es un Objeto! Esto significa entender los detalles de JavaScript, para no quedar atrapado en pegajoso pegajoso, pero bien vale la pena.

Esto significa que cuando se tiene:

var Koopa = Template.extend({ 
    hasShell: true, 
    fatalFlaw: 'shell' 
}); 

var Bowser = Koopa.extend({ 
    fatalFlaw: 'tail' 
}); 

Los datos almacenados se ve de la siguiente manera:

+-------------------. +---------------------. +---------. 
| Bowser    |->| Koopa    |->| Template | 
+--------------------+ +----------------------+ +----------+ 
|fatalFlaw => 'tail' | | hasShell => true  | | mixin | 
`-------------------+ | fatalFlaw => 'shell' | | extend | 
         `---------------------+ `---------+ 

Este diseño se deriva de diseño del padre Crockford prototypal inheritance. Y como Knuth dice: "¡La optimización prematura es la raíz de todo mal!"

Y ... si esto parece una respuesta fuera de tema, es intencionado. Debería hacer preguntas sobre cómo su diseño puede servir a sus necesidades. Si lo haces bien, entonces todo debería encajar. Si no piensas lo suficiente, puedes terminar con algunos efectos secundarios desagradables y un código apestoso. Hazte un favor y crea un diseño que elimine cualquier duda que tengas. ¡Los navegadores hacen cosas más complicadas y con uso intensivo de CPU en estos días que resolver el ajedrez!

Por lo tanto, mi respuesta es ... no escuchen lo que dice la gente sobre la eficiencia, o lo que es mejor (¡incluso yo!). Haz lo que más te parezca, en el diseño de tu biblioteca. En este momento, estás tratando de clavar una clavija cuadrada en un agujero redondo. Primero debe decidir cuáles son sus necesidades, y todo saldrá naturalmente después. ¡Incluso podría sorprenderte!