lo hace la creación de funciones consumen más memoria

Question

// Case A 
function Constructor() { 
    this.foo = function() { 
    ... 
    }; 
    ... 
} 

// vs 
// Case B 
function Constructor() { 
    ... 
}; 

Constructor.prototype.foo = function() { 
    ... 
} 

Una de las principales razones por las que aconsejan el uso de prototipos es que .foo se crea una vez en el caso del prototipo donde como this.foo se crea varias veces cuando se utiliza el otro enfoque.

Sin embargo, uno esperaría que los intérpretes puedan optimizar esto. De modo que solo hay una copia de la función foo en el caso A.

Por supuesto, usted todavía tendría un contexto de alcance único para cada objeto debido a cierres pero que tiene menos sobrecarga que una nueva función para cada objeto.

¿Los intérpretes JS modernos optimizan el Caso A por lo que solo hay una copia de la función foo?

Answer 1

Sí, la creación de funciones usa más memoria.

... y, no, los intérpretes no optimizan el Caso A hasta una sola función.

El motivo es the JS scope chain requiere que cada instancia de una función capture las variables disponibles en el momento en que se crea. Dicho esto, modern interpreters son better sobre el caso A de lo que solían ser, pero en gran parte debido a que el rendimiento de las funciones de cierre era un problema conocido hace un par de años.

Mozilla dice avoid unnecessary closures por este motivo, pero los cierres son una de las herramientas más potentes y más utilizadas en el conjunto de herramientas de un desarrollador de JS.

Actualización: acaba de ejecutar this test que crea 'casos' 1M de Constructor, usando Node.js (que es V8, el intérprete JS en Chrome). Con caseA = true consigo este uso de la memoria:

{ rss: 212291584, 
vsize: 3279040512, 
heapTotal: 203424416, 
heapUsed: 180715856 } 

Y con caseA = false consigo este uso de la memoria:

{ rss: 73535488, 
vsize: 3149352960, 
heapTotal: 74908960, 
heapUsed: 56308008 } 

Así las funciones de cierre están definitivamente consumen significativamente más memoria, por casi 3 veces. Pero en el sentido absoluto, solo estamos hablando de una diferencia de ~ 140-150 bytes por instancia. (Sin embargo, es probable que aumente según la cantidad de variables dentro del alcance que tenga cuando se crea la función).

Answer 2

Los intérpretes de JavaScript tampoco optimizan los prototipos. Es simplemente un caso de que solo haya uno por tipo (esa referencia de instancias múltiples). Los constructores, por otro lado, crean nuevas instancias y los métodos definidos dentro de ellas. Entonces, por definición, esto realmente no es una cuestión de "optimización" del intérprete, sino de simplemente entender lo que está sucediendo.

En una nota lateral, si el intérprete intentara y consolidara los métodos de instancia, se encontraría con problemas si alguna vez decidiera cambiar el valor de uno en una instancia particular (preferiría que ese dolor de cabeza no se agregue al idioma)) :)

Answer 3

Creo que, después de algunas pruebas breves en el nodo, en los casos A y B solo hay una copia del código real para la función foo en la memoria.

Caso A: hay un objeto de función creado para cada ejecución del Constructor() que almacena una referencia al código de funciones y su alcance de ejecución actual.

Caso B: solo hay un alcance, un objeto de función, compartido a través de un prototipo.