¿Por qué el JavaScript minimizado u ofuscado funciona peor que el código sin comprimir?

Encontré este informe de performance del código JavaScript comprimido usando varios minificadores y ofuscadores. Lo que es sorprendente es que, aparte del modo avanzado de Cierre, en la mayoría de los casos, todos los demás minificadores emiten código que funciona peor que el código no comprimido. ¿Cómo explicamos eso?

Desplácese hasta el final de la página para ver el informe. Aquí hay capturas de pantalla:

enter image description hereenter image description hereenter image description hereenter image description here

Leyenda:

  • Azul – Compresor YUI
  • Rojo – Cierre (modo avanzado)
  • Naranja – Cierre (modo básico)
  • Verde – JS Min
  • Púrpura – JS Packer
  • Azul claro – UglifyJS
  • Rosa – Código sin comprimir

Primero déjame jugar al abogado del diablo: el código en realidad no "realiza" nada (nada serio, quiero decir, excepto JS Packer). Es esencialmente una definición de funciones, objects y properties.

JS Packer no produce código JavaScript, sino text comprimido que debe desempaquetarse en time de ejecución. Por eso es mucho más lento. Google Closure utilizando la Optimización avanzada reemplaza los identificadores siempre que sea posible. Entonces, ya debe haber una ventaja de performance al analizar el script.

Dicho esto, es posible sacrificar el performance por el tamaño del código. Un ejemplo es replace true y false con !0 y !1 . Sin embargo, depende del motor de JavaScript. Podría ser optimizado por el motor antes de la primera llamada, después de ella, después de algunas llamadas, nunca … quién sabe;)

Nuevos hallazgos

Hice algunos perfiles mientras tanto y me di count de que había olvidado una cosa: recolección de basura. La influencia puede ser suficiente para explicar algunas de las diferencias entre los scripts y los browseres (¡diferentes motores!).

Combina eso con el hecho de que el código no hace mucho y tienes algo. En una testing, tuve un time de CPU para la recolección de basura de aproximadamente 3% para sin comprimir y 9% (!) Para JSMin. Lo que significa resultados completamente diferentes para código casi igual.

Incluso hallazgos más nuevos

Cuando ejecuta JSMin primero, es más rápido que sin comprimir. Intenté esto varias veces y siempre obtuve el mismo resultado. Esto confirma los hallazgos anteriores. Estoy bastante seguro ahora, que encontramos la solución.

Sí, la ofuscación puede causar algunos problemas de performance, pero no es cierto que el código minificado tenga un performance peor que el descomprimido. De hecho, el código minificado funciona mejor que el descomprimido. ¡Esto se debe a que el código minfied tiene un nombre de variable / function mucho más corto, lo que hace que la llamada de reference al espacio de memory asignada sea mucho más fácil!

Parece que has confundido inadvertidamente la minificación con la ofuscación.

Para entender las dos tecnologías, las explicaré por separado.

La minificación es un process en el que el tamaño de un file fuente se networkinguce y se convierte en un formatting destinado a una legibilidad de la máquina más eficiente. Esto se hace (a) eliminando comentarios y espacios en blanco innecesarios, y posiblemente (b) reemplazando nombres de variables con nombres de variables simples e incrementales que a menudo comienzan con un carácter. El código resultante sigue funcionando igual que el código original, pero teóricamente es más rápido de analizar y comstackr.

La ofuscación es una técnica en la que el código se modifica para que ya no sea reconocible como el código fuente original, y se usa a menudo para desalentar la ingeniería inversa del código propietario. Algunos de los cambios pueden tener una sobrecarga, por ejemplo, el código puede cifrarse y descifrarse nuevamente en time de ejecución. Dicho esto, es típico que un ofuscador de código también finalice el trabajo al minimizar la salida.

Sin embargo, uno podría considerar que la minificación es una forma cruda de ofuscación, pero normalmente dichos processs se llevan a cabo más para fines de performance y / o ancho de banda.