Rendimiento de Scala para Android

Para explicar un poco @Aneesh respuesta – Sí, no hay trabajo adicional para interpretar Scala bytecode, porque es exactamente los mismos bits y piezas como Java bytecode .

Tenga en cuenta que también hay un bytecode Java => paso de bytecode Dalvik cuando ejecuta código en Android.

Pero usando los mismos ladrillos uno puede construir un bikeshed y el otro individuo puede construir un townhall. Por ejemplo, debido al hecho de que el lenguaje fomenta la inmutabilidad Scala genera una gran cantidad de objetos vivos cortos. Para JVMs maduras como HotSpot no es un gran negocio para alrededor de una década. Pero para Dalvik es un problema (antes de las versiones recientes, el agrupamiento de objetos y la reutilización de objetos ya creados era uno de los consejos de rendimiento más comunes incluso para Java).

A continuación, escribir val no es lo mismo que escribir final Foo bar = ... Internamente, este código se representa como un campo + getter (a menos que prefixe val con private [this] que será traducido al campo final usual). var se traduce en campo + getter + setter. ¿Por qué es importante?

Las versiones anteriores de Android (antes de 2.2) no tenían JIT en absoluto, por lo que esto resulta a cerca de 3x-7x pena en comparación con el acceso directo al campo . Y, por último, mientras Google le ordena evitar las clases internas y prefiere los paquetes en su lugar , Scala creará muchas clases internas incluso si no lo escribe. Considere este código:

 object Foo extends App { List(1,2,3,4) .map(x => x * 2) .filter(x => x % 3 == 0) .foreach(print) } 

¿Cuántas clases internas serán creadas? No se puede decir nada, pero si se ejecuta scalac se verá:

 Foo$$anonfun$1.class // Map Foo$$anonfun$2.class // Filter Foo$$anonfun$3.class // Foreach Foo$.class // Companion object class, because you've used `object` Foo$delayedInit$body.class // Delayed init functionality that is used by App trait Foo.class // Actual class 

Así que habrá algún castigo, especialmente si escribes código idiomático Scala con mucha inmutabilidad y azúcar sintáctico. La cosa es que depende en gran medida de su despliegue (¿se dirigen a dispositivos más nuevos?) Y patrones de código reales (siempre se puede volver a Java o al menos escribir menos código idiomático en puntos críticos de rendimiento) y algunos de los problemas mencionados allí ser abordado por el propio lenguaje (el último) en las próximas versiones.

La fuente original de la imagen era Wikipedia .

Véase también Stack Overflow question ¿Está utilizando Scala en Android vale la pena? ¿Hay un montón de gastos generales? ¿Problemas? por posibles problemas que pueda encontrar durante el desarrollo.

He encontrado este documento mostrando algunos puntos de referencia entre los dos idiomas:

http://cse.aalto.fi/en/midcom-serveattachmentguid-1e3619151995344619111e3935b577b50548b758b75/denti_ngmast.pdf

No he leído el artículo completo, pero al final parece que van a dar un punto a Java:

En conclusión, creemos que Scala no jugará un papel importante en el desarrollo de aplicaciones móviles en el futuro, debido a la importancia de mantener un bajo consumo de energía en el dispositivo. El punto fuerte del lenguaje Scala es la forma en que sus componentes escalan, lo que no es de gran importancia en dispositivos móviles donde las aplicaciones tienden a no escalar en absoluto y permanecer pequeñas.

Créditos a Mattia Denti y Jukka K. Nurminen de la Universidad de Aalto.

Si bien Scala "sólo funcionará", porque está compilado en código de bytes igual que Java, hay problemas de rendimiento a considerar. El código Idiomatic Scala tiende a crear objetos mucho más temporales, y la VM Dalvik no se toma demasiado amablemente a estos.

Aquí hay algunas cosas que debe tener cuidado al usar Scala en Android:

• Vectores, ya que pueden ser un desperdicio (siempre tomar arrays de 32 elementos, incluso si usted tiene un solo elemento)
• Encadenamiento de métodos en colecciones – debe utilizar .view siempre que sea posible, para evitar la creación de colecciones redundantes.
• Boxeo – Scala encajonará a sus primitivos en varios casos, como usar Generics, usar la opción [Int], y en algunas funciones anónimas.
• para los lazos pueden desperdiciar memoria, considere reemplazarlos con bucles while en secciones sensibles
• Conversiones implícitas: llamadas como str.indexWhere(...) asignará un objeto wrapper a la cadena. Puede ser un desperdicio.
• El mapa de Scala asignará una opción [V] cada vez que acceda a una tecla. He tenido que reemplazarlo con el HashMap de Java de vez en cuando.

Por supuesto, sólo debe optimizar los lugares que son cuellos de botella después de usar un profiler.

Puede leer más sobre las sugerencias anteriores en esta entrada del blog: http://blogs.microsoft.co.il/dorony/2014/10/07/scala-performance-tips-on-android/

El compilador Scala creará código de byte JVM. Así que básicamente en el nivel inferior, es como ejecutar Java. Así que el rendimiento será equivalente a Java.

Sin embargo, la forma en que el compilador Scala crea el código de byte puede tener algún impacto en el rendimiento. Diría que desde Scala es nuevo y debido a la posible ineficiencia en su generación de código de bytes, Scala sería un poco más lento que Java en Android, aunque no por mucho.