Kotlin vs

După cum știu deja toți dezvoltatorii Android, Google a anunțat recent sprijinul oficial pentru Kotlin pe Android. Multe dintre riscurile asociate cu utilizarea acestui limbaj minunat în proiectele Android sunt eliminate. Dar este relevant, în special pentru proiectele foarte mari, care este Badoo, rămâne problema vitezei de asamblare. Am fost fericit să aflu că rețeaua are deja o cercetare pe această temă și vreau să împărtășesc unul dintre ei.

Deci, dacă traduceți o aplicație de la Java la Kotlin, va fi compilată mai mult timp?

Într-un articol anterior, am discutat despre conversia unei aplicații Android din Java în Kotlin. Codul pentru Kotlin sa dovedit a fi mai mic și a fost mai convenabil să se mențină decât Java, așa că am ajuns la concluzia că merită. Dar unii dezvoltatori nu doresc să încerce Kotlin, de teama că poate compila mai încet decât Java. Iar această preocupare este justificată: nimeni nu dorește să-și petreacă timpul convertirea codului, dacă construcția va dura mai mult. Deci, să examinăm lungimea compilației App Lock înainte și după ce am convertit la Kotlin. Nu voi compara viteza liniei Kotlin și Java cu linie, dar în schimb voi încerca să răspund la întrebarea dacă conversia întregii baze de cod dintr-o limbă în alta va afecta timpul total de construire.

Cum am testat timpul de construire

Am scris scripturi de shell pentru repetări ale ansamblurilor Gradle în diferite scenarii. Toate testele au fost efectuate de zece ori consecutiv. Înainte de fiecare script nou, proiectul a fost eliminat. Pentru scenariile care utilizează daemonul Gradle. acesta din urmă sa oprit înainte de a executa criteriul de referință.

Toate valori de referință au fost efectuate pe o mașină cu Intel Core i7-6700, care rulează la o frecvență de 3,4 GHz, echipat cu o memorie de 32 GB DDR4, și SSD-drive Samsung 850 Pro. Codul sursă a fost colectat cu ajutorul lui Gradle 2.14.1.

Am vrut să scap de valori de referință pentru mai multe cazuri de utilizare comună: asamblare pură, cu / fara demon Gradle, asamblare incrementală fără a modifica fișiere, asamblare incremental cu un fișier modificat.

Baza de date Lock din Java conținea 5491 de metode și 12 371 de linii de cod. După conversia unui număr de metode Kotlin a scăzut la 4987, iar numărul de linii - până la 8564. Procesul de conversie în arhitectura nu introduce modificări majore, astfel încât măsurarea duratei compileze înainte și după conversie este de a oferi o idee clară a diferenței de durată între ansamblul și Java Kotlin .

Curat construiește fără demon Gradle

Acesta este cel mai rău scenariu în ceea ce privește timpul de construire pentru ambele limbi: începerea unei construcții curate, cu pornire la rece. Pentru acest test, am dezactivat daemonul Gradle.

De-a lungul timpului, toate cele zece adunări au luat-

Timpul mediu de construcție al Java este de 15,5 secunde, Kotlin - 18,5 secunde: o creștere de 17%. Nu este cel mai bun început pentru Kotlin, dar majoritatea oamenilor își compun codul în alte scenarii.

Cel mai adesea, compilam de mai multe ori aceeași bază de cod ca și schimbările aduse acesteia. Pentru acest scenariu, daemonul Gradle a fost proiectat, așa că haideți să îl pornim și să vedem ce se întâmplă.

Construcții curate cu daemonul Gradle activat

Una dintre problemele cu compilatoarele JIT precum JVM este că aceștia își petrec timpul compilând codul executabil în ele, astfel încât performanța procesului crește pe măsură ce se execută. Dar dacă opriți procesul JVM, câștigul de performanță este pierdut. De fiecare dată când construiți cod Java, trebuie să porniți și să opriți JVM-ul. Ca urmare, de fiecare dată când face același lucru din nou. Pentru a rezolva această problemă, Gradle vine cu un daemon care continuă să funcționeze între ansambluri și ajută la menținerea câștigului de performanță oferit de compilația JIT. Puteți activa daemonul utilizând comanda Gradle -demon. sau adăugând org.gradle.daemon = true la fișierul gradle.properties.

Iată rezultatul executării aceleiași serii de ansambluri, dar cu daemonul inclus de Gradon:

După cum puteți vedea, prima rulare durează aproximativ același timp ca într-un scenariu fără un daemon. În ansamblurile ulterioare, performanța crește până la a patra rulare. În acest scenariu, este mai bine să estimați timpul mediu de construire după a treia etapă, când demonul sa încălzit deja. În acest caz, netul construit pe Java are o medie de 14,1 secunde, iar pe Kotlin - 16,5 secunde: o creștere de 13%.

Kotlin captează cu Java, dar rămâne în urmă. Cu toate acestea, indiferent de limba utilizată, daemonul Gradle reduce timpul de asamblare cu mai mult de 40%. Dacă nu îl folosiți încă, atunci este timpul să începeți.

Deci, construirea completă pe Kotlin rulează un pic mai lent decât Java. Dar, de obicei, ne compilam după efectuarea de modificări în doar câteva linii de cod, astfel încât ansamblurile incrementale ar trebui să demonstreze o performanță diferită. Să aflăm dacă Kotlin poate prinde Java acolo unde contează.

Creșterea incrementală

Utilizarea compilării incrementale este una dintre cele mai importante caracteristici ale compilatorului pentru a îmbunătăți performanța. În asamblare convențională recompilat toate fișierele sursă de proiect, iar pentru incrementală - ține evidența fișierelor care au schimbat de la construi anterior, și ca rezultat recompilare doar acele fișiere și cele care depind de ele. Acest lucru poate avea un efect foarte puternic asupra timpului de compilare, în special în cazul proiectelor mari.
Ansamblurile incrementale au apărut în Kotlin 1.0.2. ele pot fi incluse prin adăugarea lui kotlin.incremental = true la fișierul gradle.properties. sau prin linia de comandă.

Deci, cum va fi schimbat timpul de compilare al lui Kotlin în comparație cu Java atunci când se folosește o compilare incrementală?

Iată rezultatele benchmark-ului, cu condiția să nu existe modificări ale fișierelor:

Acum vom testa compilația incrementală dacă se modifică un fișier sursă. Pentru aceasta, am schimbat fișierul Java și echivalentul lui Kotlin înaintea fiecărui ansamblu. În acest punct de referință, acesta este un fișier asociat interfeței cu utilizatorul, alte fișiere nu depind de acesta:

În cele din urmă, să analizăm rezultatele unei compilări incrementale cu un fișier sursă modificat care este importat în multe alte fișiere de proiect:

După cum puteți vedea, daemonul Gradle trebuie încă să se încălzească timp de două sau trei runde, dar după aceea ambele limbi devin foarte aproape de performanță. Dacă nu există modificări în fișiere, Java durează 4,6 secunde pentru a încălzi ansamblul, iar Kotlin are 4,5 secunde. Dacă schimbați fișierul, dar nu este utilizat de alte fișiere, Java durează 7 secunde pentru a efectua o construcție caldă, iar Kotlin durează 6,1 secunde. În cele din urmă, dacă fișierul modificat este importat în multe alte fișiere de proiect, atunci cu daemonul Gradle încălzit, construirea Java incrementală durează 7,1 secunde, iar Kotlin durează în medie 6 secunde.

concluzie

Am măsurat performanța în mai multe scenarii diferite pentru a vedea dacă Kotlin ar putea concura cu Java pe durata compilației. Cu construiri curate care sunt relativ rare, Java depășește performanța de la Kotlin cu 10-15%. Dar, cel mai adesea, dezvoltatorii efectuează ansambluri parțiale, în care se obține un câștig mare în timp prin compilare incrementală. Datorită dracului Gradon de lucru și a compilării incrementale incluse, Kotlin nu este inferior sau chiar superior superior Java. Rezultat impresionant, pe care nu m-am așteptat. Îmi exprim teama echipei de dezvoltare Kotlin de a crea un limbaj care nu numai că are caracteristici extraordinare, ci se compilează atât de repede.

Dacă nu ați încercat Kotlin de teama de a crește timpul de compilare, atunci nu vă mai puteți face griji: se compilează la fel de repede ca Java.

Datele brute colectate de mine în timpul perioadei de referință se află aici.

Trimiteți-le prietenilor: