Innhold
Fra og med den dårligste poengsummen, 32-bit Android 5.0, viser at Java-koden gikk 296% saktere enn C, eller med andre ord 4 ganger saktere. Husk igjen at absolutt hastighet ikke er viktig her, men heller forskjellen i tiden det tok å kjøre Java-koden sammenlignet med C-koden, på samme enhet. 32-bit Android 4.4 KitKat med sin Dalvik JVM er litt raskere på 237%. Når hoppet er gjort til Android 6.0 Marshmallow begynner ting å forbedre seg dramatisk, med 64-biters Android 6.0 som gir den minste forskjellen mellom Java og C.
Den andre testen er primtallstesten, ved å bruke prøve etter inndeling. Som nevnt ovenfor bruker denne koden 64-bitlang heltal og vil derfor favorisere 64-bits prosessorer.
Som forventet kommer de beste resultatene fra Android som kjører på 64-bits prosessorer. For 64-biters Android 6.0 er hastighetsforskjellen veldig liten, bare 3%. For 64-bit Android 5.0 er den 38%. Dette demonstrerer forbedringene mellom ART på Android 5.0 og Optimalisering kompilator brukt av ART i Android 6.0. Siden Android 7.0 N fremdeles er en utviklings-beta, har jeg ikke vist resultatene, men den gir generelt sett så bra som Android 6.0 M, hvis ikke bedre. De dårligere resultatene er for 32-biters versjoner av Android, og merkelig nok 32-biters Android 6.0 gir gruppens dårligste resultater.
Den tredje og siste testen utfører en tung matematisk funksjon for en million iterasjoner. Funksjonen gjør heltall aritmetikk så vel som flytende punkt aritmetikk.
Og her for første gang har vi et resultat der Java faktisk løper raskere enn C! Det er to mulige forklaringer på dette, og begge har å gjøre med optimalisering og Optimizingkompilator fra ARM. Først Optimizing kompilatoren kunne ha produsert mer optimal kode for AArch64, med bedre registertildeling etc., enn C-kompilatoren i Android Studio. En bedre kompilator betyr alltid bedre ytelse. Det kan også være en bane gjennom koden som Optimizingkompilatoren har beregnet kan optimaliseres bort fordi den ikke har noen innflytelse på det endelige resultatet, men C-kompilatoren har ikke oppdaget denne optimaliseringen. Jeg vet at denne typen optimalisering var et av de store fokusene for Optimizingkompilatoren i Android 6.0. Siden funksjonen bare er en ren oppfinnelse fra min side, kan det være en måte å optimalisere koden som utelater noen seksjoner, men jeg har ikke oppdaget den.Den andre grunnen er at å kalle denne funksjonen, til og med en million ganger, ikke får søppeloppsamleren til å kjøre.
Som med primes-testen, bruker denne testen 64-bitlang heltal, og det er grunnen til at den neste beste poengsum kommer fra 64-biters Android 5.0. Deretter kommer 32-bit Android 6.0, etterfulgt av 32-bit Android 5.0, og til slutt 32-bit Android 4.4.
Wrap-up
Totalt sett er C raskere enn Java, men gapet mellom de to har blitt drastisk redusert med utgivelsen av 64-biters Android 6.0 Marshmallow. I den virkelige verden er selvfølgelig ikke beslutningen om å bruke Java eller C svart / hvitt. Selv om C har noen fordeler, er alle Android-brukergrensesnittet, alle Android-tjenestene og alle Android API-ene designet for å kunne kalles fra Java. C kan egentlig bare brukes når du vil ha et tomt OpenGL-lerret, og du vil tegne på det lerretet uten å bruke Android API-er.
Imidlertid hvis appen din har tunge løft å gjøre, kan disse delene porteres til C, og du kan se en hastighetsforbedring, men ikke så mye som du en gang kunne ha sett.
