La inmensa mayoría de aplicaciones en Android están escritas en el lenguaje de programación Java. Esta necesita de una máquina virtual para funcionar que durante las últimas versiones había sido Dalvik, y que en KitKat ha empezado a sustituirse por ART, una versión mucho mejor.

A raíz de este cambio los chicos de Learn OpenGL han decidido crear diversas apps para probar la velocidad de los distintos idiomas de programación y hasta qué punto aprovechan la velocidad de la CPU para ofrecer un mejor rendimiento.

Comparación de rendimiento entre ART, Dalvik y C en un Nexus 5

No entraremos en detalles técnicos, pero el autor crea un filtro DSP para generar código con mkfilter. Este se implementa de tres formas; uno en C, otra en Java y otra en Java con algunas optimizaciones manuales para aprovechar donde este idioma puede ser mejor. Unas optimizaciones que la mayoría de apps no introducen.

Los resultados se muestran en la siguiente tabla y han sido realizados sobre un Nexus5.

art-dalvik-c

Como vemos, la diferencia entre C y Java (ART y Dalvik) es enorme. Hasta casi 18 veces más lento Java en Dalvik que con apps en C.

También podemos ver como se ha mejorado mucho ART respecto a Dalvik, aunque esta diferencia sería menor si los programadores aprovechasen todas las virtudes de Java, y es que en los resultados optimizados manualmente, no se percibe tanta diferencia entre Dalvik y ART. Esta diferencia de esfuerzo no solo es cuestión de microsegundos, sino de energía utilizada por las CPUs, lo que al final se traduce en batería para nuestros dispositivos.

Unos resultados que demuestran lo increíblemente rápido que es C, el gran trabajo a pesar de ser una beta todavía que se ha hecho con ART y como de lenta es la ya algo antigua Dalvik.

Java, no tan mala elección

El autor, no contento con esto continúa su pequeño experimento y prueba el mismo código pero en un PC con un procesador Intel Core i7 a 2,6GHz, mucho más potente que el Snapdragon800 del Nexus5, pero, y aquí está lo interesante, solo se consiguen resultados 2 o 3 veces más rápido en Java, a pesar de que la CPU sea considerablemente muchísimo más rápida. Parece ser que Java no está tan mal implementado en Android.

Android_Java_

¿Cómo sería Android escrito en C? Muchísimo más rápido, con interfaces que se abren al instante y un rendimiento muchísimo mayor. ¿Por qué no entonces se apuesta por ese idioma? La razón es práctica, al ser un lenguaje de programación de bajo nivel la dificultad para crear apps en C es enorme, crear una simple app de un botón o una pantalla con un mensaje sería un verdadero quebradero de cabeza, ya no digamos apps más complejas.

Y es que al final no todo es velocidad, también el sentido práctico. Aún así una bonita comparativa que queríamos compartir con vosotros y que pone en contexto el porqué de Java como lenguaje preferido de Android.

Más información Learn OpenGL

Te puede interesar
  • Israel Gonzalez Moreno

    no entendi ni madres

    • gabboman

      Es un tema complejo, pero creo que te puedo “resumir”: en C un programa hay que traducirlo para cada CPU, esto se llama compilar (cosas de GCC y CLANG en la tabla). En java (usa davilk y art) el programa se compila una vez y vale para todas las demás. Lo que pasa es que si abarcas mucho… pues te irá más lento, pues no aprovecharas los detalles especiales de cada cpu

  • d14gvn

    Y si inventasen un lenguaje para basar a android, que esté basado en C pero que sea mucho más simple de utilizar? :O

    Ok, no, estoy soñando.

    • Luis Centeno

      Dirán que eres un soñador, pero no eres el unico
      -Johh Lennon

    • Joel Pichardo

      Entonces sera lento igual o peor que Java al inicio.

    • gabboman

      Ya está java. El problema de java es implementar una máquina virtual decente, que es lo que se está haciendo con ART. Si mejoras ART mejoras el rendimiento de todo android

      • Juan Carlos Alpizar Chinchilla

        El problema es que un código que tenga que pasar por una máquina virtual nunca va a ser tan rápido como uno que no tenga que pasar por la misma, aún así el rendimiento actual de android no es para nada deplorable

    • IvánD3

      Si quieres la eficiencia de C, tienes que lidiar con punteros. Si quieres hacer subfunciones que simplifiquen ese trabajo acabas recogiendo ineficiencia por todos lados. Algo así sucede con objetive C (el lenguaje que se utiliza en IOS) que no es tan tedioso como C, pero a cambio de ello sacrifica rendimiento (aunque no tanto como java, pero sacrificar, sacrifica)

      Otro tema sería que los desarrolladores aprendieran a programar decentemente, pero por desgracia eso no está al alcance de todos ya que lleva bastante trabajo y tiempo.

      Todo es ver como evoluciona ART, desde dalvik JIT en Android 2.2 han evolucionado una barbaridad en esos temas donde flaquea Java.
      De todos modos, viendo lo fácil que evoluciona el HW es normal que no se centren tanto en la optimización. Al final optimizar te sale más caro que mejorar el HW

      • Raúl Alexander Mendoza Muñoz

        En Java sigues usando punteros, no me vas a decir que todos los datos de una instancia de clase la guardas en la stack, guardas en el stack la dirección del objeto que creas (cuando usas el operador new) y en la memoria guardas el objeto completo.

        Siguen siendo punteros, disfrazados, pero al fin y al cabo son punteros.

        • IvánD3

          De hecho, ahi está el problema. En java practicamente todo son punteros, pero no tienes un control real y eficiente como en C/C++
          ¿Más intuitivo para el programador estándar? Si
          ¿Más eficiente? Ni de coña

          • errepunto

            La gracia está en que la máquina virtual es la que controla los punteros. Eso permite, por ejemplo, utilizar un recolector de basura, que libera memoria cuando los punteros dejan de estar usados. Eso evita muchos problemas como te olvides hacer un free después de un malloc, y evita corrupción de memoria por desbortamiento de punteros.

            El problema es que se usa más memoria y cuando el recolector de basura se pone en marcha, hay un pequeño parón.

            No obstante, para móviles sería un infierno hacer las cosas en C/C++, habría que compilarlo para cada procesador diferente y cada partición de memoria distinta, y probablemente para cada versión de Android, para que las shared library fueran correctas (seguro que no usan el mismo glibc en android 2.3 que en 4.4.2). Eso implicaría tener que subir a la tienda 20 o 30 versiones distintas, y con nuevos modelos de móvil, recompilar y subir las nuevas versiones. ¡Un infierno!

    • Astur

      Pues no habría beneficio de ningún tipo..absolutamente ninguno

  • Alfredo Figueroa

    Hagan un tema sobre Art y las apps que tienen o no conflicto con este, sería muy interesante yo queria cambiar a Art pero dicen que son varias las apps que no funcionan y no hay mucha información sobre ello

    • mani

      En el primer mes había muchas, pero yo lo tengo activado y hace muchos meses que no me da absolutamente ningún fallo.

      • Alfredo Figueroa

        Amigo pero con la app de Whatsapp no te dio problemas ¿? la verdad esta app fue la que no me dejo cambiar porque lo haría pero la mayoría de mis contactos se comunican por esta y según después ya no se podía ni instalar.

        • Razagar

          Eso fue hace tiempo, cuando acabó de salir art las aplicaciones no eran compatibles, entre ellas WhatsApp, pero ahora es raro que alguna sea incompatible. Yo lo tengo activado hace un mes en mi nexus 5 y no me falla ninguna aplicación.

          • Andres

            En que te mejoro al cambiar a ART? Ahora te dura más la batería? Más rapidez?

          • Razagar

            Pues la verdad que no he notado mucho, un amigo mio con el nexus 4 sí le va más rápido, pero el nexus 5 va más rápido de por sí. La batería también me dura lo mismo. Quizás me va más rápido la aplicación de Twitter (talon), por lo demás no he notado nada.

  • Daniel Merchán Cáceres

    como dicen que en las pruebas Java en mejor que C y al final dicen que android con C seria mas fluido?? no entendi ni madres

    • bear spirit

      lamentablemente no eso eso, es que no sabes leer. si supieses leer verias que hablan de que C en las pruebas es mejor que java

      • extremekhaos

        Y, si lo leyese todavía mejor, vería que es cierto lo que dice. A pesar de ser más lento, Java es mejor que C (que no C++). ¿Por qué? Porque la diferencia entre los tiempos de respuesta (7,99 microsegundos en Java sin optimizar, frente a 1 de C) no compensan la complejidad de programar en uno u otro lenguaje. A parte de que no congeniaría con la filosofía de Android, que es la de ser compatible con multitud de hardware diferente.

        El cuento de C le iría genial a los iPhone porque todos, absolutamente todos los terminales, los fabrica Apple con los mismos procesadores y no Samsung, LG, HTC, Sony, Acer, Xiomi y un larguísimo etc con otro enorme etc de versiones y subversiones. Por lo que ART es la alternativa perfecta a Dalvik y no “reprogramar” un SO completo y todas sus APPs en C.

        • Juan Carlos Alpizar Chinchilla

          No es que le iría genial, le va. Bueno en sí es Objective-C y no C puro, pero sigue siendo un hijo de C y aún así te apuesto que rinde mejor que los sabores de java.

          Por favor no me ataquen de apple fanboy porque tengo un S4 y me voy a comprar un HTC One M8, pero los hechos son lo que son :p

          Ahora bien una relación 1:7 yo sí la veo considerable, mucho más en términos de consumo de energía, pero el hecho es que esto no lo vas a notar sino en aplicaciones que demanden demasiado poder computacional, y las únicas que se me ocurren son escasamente los juegos o editores de video, así que como dice extremekhaos no creo que valga la pena re crear todo el código del OS sólo por eso

          • extremekhaos

            Perdón. Le va… jejejej

    • Carlos Javier

      Para que un lenguaje sea mejor que otro para desarrollar aplicaciones, no influye sólo el rendimiento del programa generado, sino la facilidad para desarrollar esos programas. Y luego, si resulta que en las aplicaciones la mayor parte del tiempo se lo pasa interactuando con el usuario en lugar de hacer un montón de cálculos complejos, ahí tiene que no salga a cuenta desarrollarla en el lenguaje más rápido, sino en el más sencillo de programar. ¿O me vas a decir que preferirías invertir 1000 horas en desarrollar un programa para obtener una ligerísima mejora en el rendimiento percibido por el usuario, en lugar de invertir 100 horas en ese mismo programa? Si el programa desarrollado en Java es suficientemente rápido, no es necesario complicar el desarrollo haciéndolo en otro lenguaje más complejo de usar.

  • unsleep

    Y por eso y mil cosas mas es por lo que no me gusta Java…

    • Astur

      Pero su curva de aprendizaje es facilisima, las cosas como son

      • unsleep

        java tiene un monton de jeroglificos y versiones, c, no los tiene

        • Jesús Martínez

          Para jeroglíficos php D; Y como dice Astur, Java es fácil… “verbouse”, pero fácil.

          • unsleep

            jeroglificos php por favor??? java prima pelada, java moviles, java tu culo, java bragas, java semana santa, java iphone, java android, java tu ano, java pedo… igual que un lenguaje no compilado pero encima peor… C es c en cualquier plataforma, igual que php, java no.

          • Jesús Martínez

            uy perdón……… pues que triste que te tomes tan personal un lenguaje de programación.

          • errepunto

            Para jeroglíficos, usa Perl XD

  • Joshua

    “La razón es práctica, al ser un lenguaje de programación de bajo nivel la dificultad para crear apps en C es enorme”

    ¿Peeeeeeeeeeerdona?

    C y Java son ambos de alto nivel, lo que cambia es el paradigma de programación

    • Manuel Echeverry

      pueda se que el autor se referia a C y no a C++ que es la versión orientada a objetos, asi como java. por que C puro, si es muy complejo en comparacion con java

  • Patricio Bosio

    Asumo que el tiempo esta medido en milisegundos… la diferencia entre 1 y 17 es casi imperceptible.
    Como programador y siendo C++ el lenguague que mas he utilizado en mi vida profesional (y el que mas me gusta) y aparte de ser toda la vida muy critico sobre el lenguague Java, creo que tiene valor que diga que la diferencia en rendimiento entre una aplicacion en C++ o Java en los dispositivos de hoy en dia es practicamente imperceptible y el esfuerzo que implica usar el NDK de Android no lo vale ya que la ganancia en rendimiento seria minima.

    • jenen

      Pero es tiempo relativo, en milisegundos no te das cuenta pero si es un juego cuyo codigo en java tarda para ejecutarse 18 segundos, en c sería 1 segundo, ahí si que se notaría la diferencia, solo que en c llevaría mucho mas tiempo programar. En los celulares de gama baja seguro que se notaría la diferencia, donde todas la aplicaciones pesadas tardan unos 5 segundo aproximadamente en abrir

      • Patricio Bosio

        Honestamente en los tiempos de carga dudo que encuentres mucha diferencia entre C++ y Java, no se si Andrioid a la hora de cargar los recursos de la App lo hace a traves de APIs nativas. La diferencia principal se encuentra en la logica de la aplicacion en si.
        En las mayorias de las apps al no tener logicas demasiadas complicadas la diferencia seria casi nula, en el unico escenario donde se me ocurre que podria llegar a notarse es en aplicaciones con logica mas compleja como los juegos.
        Pero hay que ser realistas, nadie desarrolla para dispositivos de gama baja ni les interesa, la diferencia de tiempos de desarrollo entre Java y C++ es gigante y en los dispositivos de hoy en dia, la diferencia de rendimiento seria casi imperceptible para el usuario.
        No creo que haya mucho que discutir sobre el tema, existen en internet un monton de pruebas de rendimiento entre C++ y Java, es una discusion frecuente entre programadores, la unica diferencia es que esta vez se hizo bajo un environment que no es una PC sino un Android

      • Astur

        No, una cosa es la optimización y otra cosa son los buses de datos, eso solo es inherente al hardware

  • Ricardo

    A ver, una cosa es el lenguaje y otra muy diferente es el compilador y la máquina virtual sobre la que se ejecuta el programa compilado (para el caso de Java). Android utiliza Java COMO LENGUAJE DE PROGRAMACIÓN porque es de lo más utilizado por los desarrolladores y podrían envolverse rápidamente al mundo de Android, pero sin embargo no es Java de Sun MicroSystems como tal, de hecho los archivos que traduce la máquina virtual son optimizados para móviles comparados con los clásicos .java

    La gran idea de Java, cuando surgió, fue que se podría ejecutar en cualquier computadora sin tener que volver a compilar para diferentes procesadores o arquitecturas ya que la máquina virtual lo hacía por nosotros, esta idea se llevó después al mundo del desarrollo web y ahora con los dispositivos móviles.

    Por lo que el tiempo en ejecutar una aplicación va a depender más de la máquina virtual y su optimización que del lenguaje en sí. Ahora, ¿Porqué funciona con C? Pues porque se utiliza el gcc. Que es un conjunto de compiladores (entre ellos C) para GNU, y Android dentro de sus más profundos secretos tiene un kernel de Linux, el cuál ejecuta la máquina virtual y esta ejecuta nuestras aplicaciones.

    Entonces en teoría, va a ser más rápido ejecutar una aplicación en C porque estas ejecutando directamente sobre el Kernel y no pasa por la máquina virtual que a la vez va a traducir tu código al Kernel.

    Resumen, ¿Porqué usar Java en lugar de C? Porqué más desarrolladores están acostumbrados a utilizarlos aunado a que es un lenguaje orientado a objetos contra un lenguaje estructural como C. ¿Porqué ejecutar una máquina virtual y no trabajar directo sobre el kernel? Pues es una de las ventajas de Android, olvidarte del hardware, las direcciones de memoria y las limitantes del dispositivo para programar una aplicación que va a funcionar en todos los dispositivos que corran dicha máquina virtual.

    • Raúl Alexander Mendoza Muñoz

      Por eso prefiero .Net, ya viene integrada la maquina virtual en el sistema operativo, lo cual hace una ejecución mas rápida, ademas parte del binario se compila durante la ejecución para el procesador.

      Microsoft tendrá sus puntos débiles, pero debo admitir que en una pelea de Java vs C# apuesto hacia C#.

      • Javier C

        si claro, y corre en linux, mac Os, solaris

        • Raúl Alexander Mendoza Muñoz

          ¿Has escuchado el proyecto de Mono? (Project Mono)

          • Javier C

            si, y ¿por lo menos has corrido algún programa de .net fuera de windows y de forma correcta?, ¿sin usar Wine u otro similar?
            para no ir tan lejos has usado moonlight, que es el equivalente a silverlight, y que fue un fracaso total

          • Raúl Alexander Mendoza Muñoz

            Hasta el Framework 3.5 de .Net si, ya en versiones posteriores no me toco trabajar con Mono.

      • errepunto

        Java no es más lenta que C#, es más, en ningún benchmark que haya visto supera la plataforma .net a hotspot en velocidad.

        Otra cosa es que C# tenga una muy buena integración con entornos windows y, por qué no decirlo, las interfaces gráficas hechas en .Net funcionan bastante mejor que el apestoso swing (y lo digo como programador Java :D)

        • Raúl Alexander Mendoza Muñoz

          Y eso que no te toco trabajar con la AWT, pero problema viene al querer visualizar de manera similar en diferentes plataformas un mismo ejecutable. Por eso las librerías de gráficos de .Net son mejores, ya que solo se preocupan en Windows.

          • errepunto

            ¡AWT es el horrooooor!

    • suponzio

      No tienes ni idea de lo que estás hablando. Cuando se programa en C no se trabaja directamente sobre el kernel. Se trabaja con las librerías del sistema y estas son las que tocan el kernel. Si tocásemos directamente el kernel corromperíamos el sistema. Además de que no se puede, no se tiene ese permiso sobre la memoria. Aunque tal vez si es un microkernel se puedan tocar los módulos de este…

      • Ricardo

        Tienes razon, exagere sobre el trabajar directamente sobre el kernel; sin embargo no quiere decir que no tenga idea de lo que estoy hablando, lo que queria resaltar es que trabajando en C te evitas el tener que pasar por una maquina virtual, que mucho o poco pero va a afectar en el rendimiento a costa de un ambiente de desarrollo mas seguro, bonito y facil de usar.

  • Bruno Alcalde

    En mi.moto g sale la opción de vambiar a ART, pero cuando reinicia y veo, sigue en Dalvik

    • Astur

      Tienes instalado Xposed?

      • nacaballero

        Me pasa exactamente lo mismo, y tengo instalado Xposed.. Será ese el problema?

        • Gera

          Pues sí, Xposed no es compatible con ART, sólo con Dalvik.

        • Carlos

          Si, ese es el problema, Xposed aún no puede trabajar con ART sino que solo con dalvik, en el caso del moto g si compraste el de 8 gb esta mejor en dalvik ya que en ART ocupan mas espacio las aplicaciones

      • Bruno Alcalde

        Sí. Tengo Xposed y cwm de recovery

        • Astur

          Pues ahí tienes la razón, shur

    • Manuel Echeverry

      igual metrerse con ART a estas alturas que esta en beta es un juego de suerte. algunas apps funcionaran bien, y otras daran muchos problemas o errores inesperados.

  • Miguel Méndez

    Personalmente prefiero C#, su desventaja sería en cuanto a la dependencia de .NET Framework y Microsoft, o sea, la ausencia de soporte multiplataforma.

    • Manuel Echeverry

      osea una total mier…. lo único bueno de C# es un interoperatividad con otros lenguajes gracias al código intermedio MSIL, pero como dices, eso solo es posible con el Framework de .NET

    • miguelpedregosa

      De guatemala a guatepeor …

  • Andrés Blasco

    Si por lo menos optimizasen…

  • Elvin

    C alto nivel? Q diablos estas hablando…

    • Raúl Alexander Mendoza Muñoz

      Es de alto nivel C, si quieres bajo nivel usa Ensamblador.

      • Jorge Martín

        Qué coño ensamblador, ¡usa binario! O eso es demasiado moderno, mejor por pulsos electromagnéticos. Eso sí que es bajo nivel.

    • errepunto

      Cualquier lenguaje que en vez de “compara estos registros y si el resultado es cero salta a esta dirección de memoria y decrementa el contador” tenga un “haz esto 10 veces” ES de alto nivel :D

6 de 14