Rendimiento en DART, JavaScript y V8

He podido leer una consulta que realizaba una persona en la lista de distribución de DART que considero bastente importante a tener en cuenta para cualquiera que esté desarrollando actualmente con DART y necesite un rendimiento crítico.

Como sabes actualmente DART está en pleno desarrollo intentando alcanzar una fase un poco más estable antes de finales de año, la milestone 1 o M1 como se conoce normalmente.

A día de hoy DART no corre de manera nativa. La forma de funcionar es la siguiente:

  • Escribes tu código en DART.
  • Compilas a JavaScript.
  • Ejecutas tu aplicación en Google Chrome o en otro navegador con Chrome Frame.

Según esta estructura, nuestro código, nuestra aplicación finalmente es JavaScript y corre en el motor V8 de JavaScript de Chrome, por lo que debes tener muy presente las optimizaciones y la mejor forma de funcionar en V8.

Un usuario preguntaba si una función debe retornar un único objeto, qué es mejor, retornar un valor o una excepción en caso de que se produzca un error dentro de la función.

Florian Loitsch proporciona una respuesta donde detalla ciertas cuestiones importantes a la hora de escribir nuestro código.

No es explica que, si nuestros requisitos de rendimiento son muy críticos debemos escribir funciones sin try/catch debido a que actualmente los try/catch no son optimizables en v8. En un futuro esto cambiará, pero actualmente no lo son. Por tanto, una función con try/catch es más lenta que una que no contiene bloque de control de excepciones.

Además, y creo que es aquí donde viene lo más interesante, V8 y DART utilizan type-feedback (realimentación de tipos de datos) para optimizar el código, por lo que si la función nunca devuelve una excepción en caso de error, el sistema nunca sabrá que se debe retornar un tipo de dato diferente. A pesar de ello, podría no tener un impacto considerable en el rendimiento (depende del código y del optimizador).

Si echamos un vistazo al código de las librerías escritas por Google, están bien estructuradas, con tests unitarios y sin bloques try/catch. Lanzan excepciones en caso de error. Por lo que estoy seguro que los bloques try/catch consumen tiempo y rendimiento.

Como pude leer una vez:

“La linea de código más rápida del mundo es la que no se ejecuta.”

No obstante siguamos las recomendaciones de Florian. Si no necesitamos un rendimiento crítico utilicemos bloques try/catch para controlar errores inesperados y podamos tener un código más legible y mantenible.

Adjunto las preguntas respuestas de la lista:

Q:
In case a function can dynamically return only one of these objects:
– either a regular object of one type/interface that has only one class as implementation.
– or an error message of the always the same Error type.

What would be the technically most efficient solution ?
A dynamically typed return value or passing the error as exception ?

A:
If you have performance critical code you are usually better off not using try/catch. In the current v8 a try/catch statement makes the function non-optimizable. This should (hopefully) eventually be fixed, but even then it will probably still be slower than a function that does not contain any try/catch. Note however that this only concerns the function that actually contains the try/catch statement. Throwing an exception should be fine.
V8 and Dart use type-feedback to optimize code. So if your function never returns the exception-object it will not even know that a different type could be returned. Even if the exception object is returned it could have nearly no impact on performance (depends on the new live code and how the optimizer arranges the type-tests).

If your code is not performance critical try to stick with try/catch since this is the agreed upon way to deal with errors, and makes your code more readable and maintainable.
// florian

Artículo escrito por Moisés Belchín

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s