¿Cómo funciona la memoria JavaScript en los navegadores?

Al compilar interfaces JS avanzadas y juegos, he descubierto que tengo que profundizar en la forma en que los navegadores manejan la memoria para JS. Mi experiencia con la memoria y JavaScript es que la memoria se glogged (y hace animaciones y cálculo lenta/retraso) cuando:¿Cómo funciona la memoria JavaScript en los navegadores?

hay un montón de contenido generado por JS en la página
Hay un montón de gráficos (img-elements) en la página?

Por lo tanto, he llegado a la conclusión de que si quiero mantener mi memoria fresca debería incluir tanto código HTML como sea posible desde el principio del documento, ya que se almacenará en caché y no se guardará en la memoria. Y, por supuesto, eliminar todos los elementos actualmente no utilizados.

¿Alguien tiene más información sobre esto? Recursos? ¿Campo de golf?

Fuente

2009-11-02 Jens

¿Qué quiere decir exactamente "en caché y no guardado en la memoria"? Eso no tiene ningún sentido para mí. –

No soy un experto en hardware en este caso. Creo que creo que hay una diferencia si un archivo se lee de la memoria caché o memoria. Pero, de nuevo, tal vez todos los archivos en caché se pasan a través de la memoria. O tal vez la memoria es lo mismo que la caché en este ejemplo. Como dije, realmente no sé cómo encaja todo. Es por eso que pregunto :) – Jens

algunas cosas a tener en cuenta:

IE muere por DOM complejidad. Cuantos más elementos forman parte de la página, más lento se vuelve. He visto que las páginas se ralentizan notablemente con tan solo 3000 elementos (si tienes una cuadrícula con 10 columnas y 100 filas, eso es 1000 elementos ahí). El enfoque correcto suele ser descargar partes ocultas del DOM (separarlas)
IE también tiene un largo historial de no liberar correctamente los elementos HTML si tienen controladores de Javascript adjuntos. Si tiene una página de larga duración que a menudo se actualiza, consulte las pérdidas de memoria de IE y cómo solucionar estos problemas.
Todos los navegadores almacenan las imágenes sin comprimir en la memoria. Por lo tanto, si está precargando un montón de imágenes grandes en segundo plano, generalmente es una mala idea.
La actualización de las propiedades DOM provocará el reflujo de página, que en páginas complejas puede llevar mucho tiempo. En ocasiones, incluso recuperar propiedades de DOM (por ejemplo, offsetHeight) será muy lento.

En general, JavaScript no es un cuello de botella de rendimiento. Lo que lo mata es la interacción con el DOM.El código que no toca el DOM raramente tiene problemas de rendimiento. Aquí solo hay reglas generales: interactúe con DOM lo menos posible, mantenga la complejidad de DOM lo más baja posible, evite los reflujos de página repetidos.

Fuente

2009-11-02 16:39:57

Muy bien. Entonces, la interacción con el DOM también es un problema. Especialmente uno grande. Bueno saber. ¿Qué sucede si cambio/reduzco el árbol DOM? ¿Eso agrega a la memoria (almacena las revisiones?) ¿O eso realmente aligera la carga? ¿Con "reflujos de página" quiere decir una actualización de todos los elementos de documentos de acuerdo con el modelo de formato visual? – Jens

Puede encontrar esto útil: http://www.slideshare.net/lsimon/go-with-the-reflow, también, esto: https://library.mozilla.org/Faster_HTML_and_CSS:_Layout_Engine_Internals_for_Web_Developers –

El árbol DOM no es revisado. Si extrae algo del árbol DOM, y no tiene referencias de javascript (no tan fácil como suena, debido a las cadenas de prototipos), se recogerá basura. –

Para empezar. Todo el HTML, ya sea "incluir desde el principio" o no, se guarda en la memoria. Lo más probable es que también todo el contenido de la imagen de la página actual. Como mínimo, todo lo que ve en la pantalla en un momento dado se guarda en la memoria en ese momento.

Fuente

2009-11-02 14:55:53

Solo pensé que hay un límite en la forma en que los navegadores manejan la memoria. Quiero decir, puedes hacer scripts mucho más intensos en flash que lo que puedes hacer en JavaScript antes de que te corras a problemas de retraso. Algo está reteniendo mi scripting ¿verdad? Algunas restricciones a las secuencias de comandos del navegador en generall? – Jens

Puede hacer scripts mucho más intensos en Flash porque tiene un motor de script muy rápido. Una variante de ese motor (Tamarin) ahora está en Firefox, mientras que Safari y Chrome tienen sus propias nuevas ridículamente rápidas. Alas Internet Explorer se está quedando atrás algo. –

Ah, yo c. Entonces, es el motor lento y viejo. Figuras Realmente me gusta el motor de Chromes. – Jens

Para ser honesto, tiende a depender más de lo que haces con él. Una gran cantidad de gráficos no van a hacer cuclillas a javascript si no estás interactuando con ellos, pero si tienes una página enorme llena de diferentes elementos y estás buscando todo el documento para un solo elemento, entonces eso es diferente cosa completamente

He tenido problemas para agregar cosas masivas a las páginas. Ejecutando demasiados bucles en una página y demasiados temporizadores.

Si el rendimiento de JavaScript es un problema y planea hacer javascript intensivo, es posible que desee consultar webworkers. He aquí unos cuantos enlaces en webworkers:

Fuente

2009-11-02 14:56:48 Steerpike

Usar webworkers no es la transmisión principal todavía. Los navegadores modernos aún no han llegado al mundo rural de la web. –

Lectura interesante. Alltough to Beta para mí :) – Jens

¿Cómo funciona la memoria JavaScript en los navegadores?

Respuesta

Cuestiones relacionadas