Sisu
Alustades halvimast hindest, 32-bitine Android 5.0, näitab, et Java-kood jooksis 296% aeglasemalt kui C ehk teisisõnu 4 korda aeglasem. Pidage jälle meeles, et absoluutkiirus ei ole siin oluline, vaid pigem Java-koodi käivitamiseks kuluv aeg võrreldes C-koodiga samas seadmes. 32-bitine Android 4.4 KitKat koos oma Dalvik JVM-iga on pisut kiirem - 237%. Kui Android 6.0-le on hüpatud, hakkavad Marshmallow asjad dramaatiliselt paranema. 64-bitine Android 6.0 annab Java ja C vahel väikseima erinevuse.
Teine test on algarvu test, kasutades katselist jaotust. Nagu eespool märgitud, kasutab see kood 64-bitistpikk täisarvud ja eelistavad seetõttu 64-bitiseid protsessoreid.
Ootuspäraselt annavad parimad tulemused 64-bitiste protsessoritega töötav Android. 64-bitise Android 6.0 puhul on kiiruse erinevus väga väike, vaid 3%. 64-bitise Android 5.0 puhul on see 38%. See näitab parandusi Android 5.0 ja ART versioonide vahel Optimeerimine kompilaator, mida ART kasutab Android 6.0-s. Kuna Android 7.0 N on endiselt arendus beetaversioon, pole ma tulemusi näidanud, kuid see toimib üldiselt sama hästi kui Android 6.0 M, kui mitte parem. Halvemad tulemused on Androidi 32-bitistel versioonidel ja kummalisel kombel annab 32-bitine Android 6.0 grupi halvimaid tulemusi.
Kolmas ja viimane test täidab raske matemaatilise funktsiooni miljoni iteratsiooni korral. Funktsioon täidab nii täisarvude kui ka ujukomaaritmeetilisi väärtusi.
Ja siin on meil esimest korda tulemus, kus Java töötab tegelikult kiiremini kui C! Sellel on kaks võimalikku seletust ning mõlemad on seotud optimeerimise ja O-gaptimiseeriminekoostaja ARM-ist. Esiteks, Optimiseerimine kompilaator oleks võinud AArch64 jaoks optimaalsema koodi koos parema registripaigutusega jne luua kui Android Studio C kompilaator. Parem kompilaator tähendab alati paremat jõudlust. Samuti võiks olla tee läbi koodi, mille Optimiseeriminekompilaatori arvutatud saab optimeerida, kuna see ei mõjuta lõpptulemust, kuid C-kompilaator pole seda optimeerimist märganud. Ma tean, et selline optimeerimine oli O-le üks suuremaid fookusiptimiseeriminekoostaja Android 6.0-s. Kuna funktsioon on minu jaoks lihtsalt puhas leiutis, võiks olla võimalus optimeerida koodi, mis jätab mõned lõigud vahele, kuid ma pole seda märganud.Teine põhjus on see, et selle funktsiooni kutsumine, isegi miljon korda, ei põhjusta prügikogujat.
Nagu PRIMESi test, kasutab see test 64-bitistpikk täisarvud, mistõttu järgmine parim tulemus pärineb 64-bitisest Android 5.0-st. Seejärel tuleb 32-bitine Android 6.0, millele järgneb 32-bitine Android 5.0 ja lõpuks 32-bitine Android 4.4.
Tõmba otsad kokku
Üldiselt on C kiirem kui Java, kuid lõhe nende kahe vahel on 64-bitise Android 6.0 Marshmallow väljalaskega dramaatiliselt vähenenud. Muidugi pole reaalajas otsus Java või C kasutamise kohta must-valge. Kuigi C-l on mõned eelised, on kogu Androidi kasutajaliides, kõik Androidi teenused ja kõik Androidi API-d kavandatud helistama Java-st. C saab tõesti kasutada ainult siis, kui soovite tühja OpenGL-lõuendit ja soovite sellele lõuendile joonistada ilma Android-i API-sid kasutamata.
Kuid kui teie rakendusel on raske teha raskusi, siis võiks need osad teisaldada C-sse ja võite näha kiiruse paranemist, kuid mitte nii palju kui kunagi varem oleksite võinud näha.
