Contenu
En commençant par le plus mauvais score, Android 5.0 32 bits, montre que le code Java a été exécuté 296% plus lentement que le code C, soit 4 fois plus lentement. Encore une fois, rappelez-vous que la vitesse absolue n’est pas importante ici, mais plutôt que le temps nécessaire pour exécuter le code Java par rapport au code C sur le même appareil est différent. Android 4.4 KitKat 32 bits avec sa JVM Dalvik est un peu plus rapide à 237%. Une fois que le saut est fait sur Android 6.0, les choses commencent à s’améliorer de façon spectaculaire, avec Android 6.0 64 bits offrant la plus petite différence entre Java et C.
Le second test est le test du nombre premier, qui utilise procès par division. Comme indiqué ci-dessus, ce code utilise 64 bitslongue entiers et favorisera donc les processeurs 64 bits.
Comme on pouvait s'y attendre, les meilleurs résultats proviennent d'Android fonctionnant sur des processeurs 64 bits. Pour Android 6.0 64 bits, la différence de vitesse est très petite, seulement 3%. Tandis que pour Android 5.0 64 bits, il est de 38%. Ceci démontre les améliorations entre ART sur Android 5.0 et la L'optimisation compilateur utilisé par ART dans Android 6.0. Étant donné qu'Android 7.0 N est encore une version bêta du développement, je n'ai pas montré les résultats, mais ses performances sont généralement aussi bonnes que celles d'Android 6.0 M, sinon mieux. Les pires résultats concernent les versions 32 bits d'Android et, curieusement, Android 6.0 32 bits génère les pires résultats du groupe.
Le troisième et dernier test exécute une lourde fonction mathématique pour un million d'itérations. La fonction utilise l'arithmétique entière ainsi que l'arithmétique à virgule flottante.
Et ici, pour la première fois, nous avons un résultat où Java est en fait plus rapide que C! Il y a deux explications possibles à cela: l’optimisation et le comportement Optimisercompilateur d'ARM. Tout d'abord, le Optimiser Le compilateur aurait pu produire un code plus optimal pour AArch64, avec une meilleure allocation des registres, etc., que le compilateur C dans Android Studio. Un meilleur compilateur signifie toujours de meilleures performances. Il pourrait également y avoir un chemin à travers le code que le OptimiserLe compilateur a calculé peut être optimisé car il n’a aucune influence sur le résultat final, mais le compilateur C n’a pas détecté cette optimisation. Je sais que ce type d’optimisation a été l’un des grands objectifs de l’Optimisercompilateur dans Android 6.0. Comme cette fonction n’est qu’une pure invention de ma part, il pourrait exister un moyen d’optimiser le code en omettant certaines sections, mais je ne l’ai pas encore vue.L'autre raison est que l'appel de cette fonction, même un million de fois, ne provoque pas l'exécution du ramasse-miettes.
Comme pour le test des nombres premiers, ce test utilise une résolution 64 bits.longue nombres entiers, ce qui explique pourquoi le prochain meilleur score vient d’Android 5.0 64 bits. Vient ensuite Android 6.0 32 bits, suivi d'Android 5.0 32 bits et enfin d'Android 4.4 32 bits.
Emballer
Globalement, le C est plus rapide que Java, mais l’écart entre les deux a été considérablement réduit avec la sortie d’Android 6.0 Marshmallow 64 bits. Bien sûr, dans le monde réel, la décision d’utiliser Java ou C n’est pas noire ou blanche. Bien que C présente certains avantages, l’ensemble de l’interface utilisateur Android, tous les services Android et toutes les API Android sont conçus pour être appelés à partir de Java. C ne peut vraiment être utilisé que lorsque vous voulez un canevas OpenGL vierge et que vous voulez dessiner sur ce canevas sans utiliser d’API Android.
Cependant, si votre application doit faire face à de lourdes tâches, ces pièces pourraient être portées en C et vous pourrez constater une amélioration de la vitesse, mais pas autant que vous auriez pu le voir une fois.
