Recientemente, se han publicado algunos artículos geniales sobre este tema. Hay algunas fuentes realmente sorprendentes de creación de objetos que realmente no llaman tu atención a menos que estés sintonizado. Normalmente, el problema no es el uso de la memoria, sino los ciclos de recolección de basura necesarios para recolectar la memoria que la aplicación está perdiendo lentamente.
Este artículo es el mejor que he leído sobre el tema recientemente: http://www.scirra.com/blog/76/how-to-write-low-garbage-real-time-javascript
cuanto a las herramientas para combatir/diagnosticar el problema, Speedtracer de Google Chrome viene a la mente. Por supuesto, afinar Chrome no garantiza el ajuste para todos los navegadores, pero la mayoría de las cosas que resultan en la creación de objetos en Chrome son comunes a las especificaciones de JS ya que todos los navegadores las implementan.
Una cosa importante a tener en cuenta es que el uso de la RAM y el uso de la RAM de video no son lo mismo. Una práctica recomendada es determinar qué partes de su UI están siendo aceleradas por hardware y para asegurarse de que sean pequeñas (es decir, quepan en pantalla de una sola vez). Si tienes grandes porciones de desplazamiento del hardware de la pantalla aceleradas, obtendrás GPU rasgado/mosaico y desplazamiento lento. Puedes detectar esto en parte usando el simulador de iOS. Este artículo cubre la idea brevemente: http://devinsheaven.com/turn-your-iphone-wacky-and-make-your-iphone-application-better/
Por último, hay un montón de patrones de memoria con fugas muy comunes en JavaScript que cada ingeniero se encuentra de vez en cuando. IBM tiene una buena lista de ellos. No puedo publicar más de dos enlaces porque soy un n00b, pero puedes buscar "Fugas de memoria de JavaScript comunes" en Google y probablemente sea el primer resultado.