Velocidad del objeto matemático en Javascript

Question

Estoy trabajando en una aplicación de JavaScript que hace un uso intensivo de las operaciones matemáticas, docenas de llamadas por movimiento de mouse. He estado trabajando en el código de la gente de los demás como punto de partida, y me encuentro a menudo arounds de trabajo para la matemáticas Javascript nativa, tales como ...

var pi = Math.PI 
var distance = (x * x) + (y * y)/R * R 
var pixels = ~~(x/y) 

¿Existe un significativo impacto en el rendimiento para el uso del objeto Math ? Si es así, ¿cuáles son algunas soluciones comunes?

Answer 1

Si por alguna razón hacer el cálculo de la materia intensiva en javascript, debe recordar esas cosas (* y leer de David Mandelin Sepa sus motores: Cómo hacer que su JavaScript rápida presentación - PDF, donde describe esto con más detalles *):

1. en línea todo lo que pueda.

2. llamadas a funciones son muy caros

3. acceso a objetos es caro

4. polimorfismo puede costar rendimiento, sus variables y argumentos debe sujetarse siempre sólo un tipo de datos.

objeto Math no es especialmente lento, pero que no encontrará distance() función allí de todos modos, y acceder a sus métodos de cierre a través de las llamadas es Math.method(), ineficiente.

por lo sqrt es, por supuesto, peor que x*x, a medida random función podría ser mejor para usted, Pi debe almacenar en caché en los bucles, min y max probablemente se debe evitar, así, ninguna idea acerca de la trigonometría y logaritmos de velocidad .

---

P.S .: Puede hacer cosas como ((x >= 0 ? x : -x) + 0.5) >> 0, para reemplazar Math.ceil(Math.abs()), pero recuerda - cuando digo "intensivo" - estoy hablando de procesamiento de números, procesamiento de datos, la física, gráficos y cosas por el estilo. Para sitios normales de JavaScript o RIA, usted no debe hacer cosas que estoy sugiriendo aquí. Además, la mayoría de los hacks de velocidad tienen su side effects

Answer 2

No estoy de acuerdo con las llamadas de función. if las sentencias dentro de las sentencias if y las funciones especializadas largas son más lentas que el código bien organizado con muchas funciones pequeñas generalizadas.