Mi sono imbattuto in Xamarin affermando che la loro implementazione Mono su Android e le loro app compilate in C # sono più veloci del codice Java. Qualcuno ha eseguito benchmark effettivi su codice Java e C # molto simile su piattaforme Android diverse per verificare tali affermazioni, potrebbe pubblicare il codice e i risultati?

Aggiunto il 18 giugno 2013

Dal momento che non c'era risposta e non è stato possibile trovare tali parametri di riferimento fatti da altri, ho deciso di fare i miei test. Sfortunatamente, la mia domanda rimane "bloccata", quindi non posso pubblicarla come risposta, ma solo modificare la domanda. Si prega di votare per riaprire questa domanda. Per C #, ho usato Xamarin.Android Ver. 4.7.09001 (beta). Il codice sorgente, tutti i dati che ho usato per i test e i pacchetti APK compilati sono su GitHub:

Java: https://github.com/gregko/TtsSetup_Java

C #: https://github.com/gregko/TtsSetup_C_sharp

Se qualcuno volesse ripetere i miei test su altri dispositivi o emulatori, sarei interessato a conoscere anche i risultati.

Risultati dei miei test

Ho portato la mia classe di estrattore di frasi su C # (dalla mia app @Voice Aloud Reader) ed ho eseguito alcuni test su 10 file HTML in inglese, russo, francese, polacco e ceco. Ogni esecuzione è stata eseguita 5 volte su tutti e 10 i file e il tempo totale per 3 diversi dispositivi e un emulatore sono riportati di seguito. Ho testato solo build "Release", senza debug abilitato.

HTC Nexus One Android 2.3.7 (API 10) - CyanogenMod ROM

Java: tempo totale complessivo (5 esecuzioni): 12361 ms, con totale lettura file: 13304 ms

C #: tempo totale complessivo (5 corse): 17504 ms, con totale lettura file: 17956 ms

Samsung Galaxy S2 SGH-I777 (Android 4.0.4, API 15) - CyanogenMod ROM

Java: tempo totale complessivo (5 esecuzioni): 8947 ms, con totale lettura file: 9186 ms

C #: tempo totale complessivo (5 corse): 9884 ms, con totale lettura file: 10247 ms

Samsung GT-N7100 (Android 4.1.1 JellyBean, API 16) - Samsung ROM

Java: tempo totale complessivo (5 esecuzioni): 9742 ms, con totale lettura file: 10111 ms

C #: tempo totale complessivo (5 corse): 10459 ms, con lettura totale del file: 10696 ms

Emulatore - Intel (Android 4.2, API 17)

Java: tempo totale complessivo (5 esecuzioni): 2699 ms, con totale lettura file: 3127 ms

C #: tempo totale complessivo (5 corse): 2049 ms, con lettura totale del file: 2182 ms

Emulatore - Intel (Android 2.3.7, API 10)

Java: tempo totale complessivo (5 esecuzioni): 2992 ms, con totale lettura file: 3591 ms

C #: tempo totale complessivo (5 corse): 2049 ms, con totale lettura file: 2257 ms

Emulatore - Arm (Android 4.0.4, API 15)

Java: tempo totale complessivo (5 esecuzioni): 41751 ms, con totale lettura file: 43866 ms

C #: tempo totale complessivo (5 corse): 44136 ms, con totale lettura file: 45109 ms

Breve discussione

Il mio codice di prova contiene principalmente analisi del testo, sostituzione e ricerche Regex, forse per altri codici (ad es. Più operazioni numeriche) i risultati sarebbero diversi. Su tutti i dispositivi con processori ARM, Java ha funzionato meglio del codice Xamarin C #. La differenza più grande era su Android 2.3, dove il codice C # viene eseguito a ca. 70% della velocità di Java.

Sull'emulatore Intel (con tecnologia Intel HAX, l'emulatore funziona in modalità virt veloce), il codice Xamarin C # esegue il mio codice di esempio molto più velocemente di Java, circa 1,35 volte più veloce. Forse il codice e le librerie della macchina virtuale Mono sono ottimizzati molto meglio su Intel che su ARM?

Modifica 8 luglio 2013

Ho appena installato l'emulatore Android Genymotion, che funziona in Oracle VirtualBox, e di nuovo questo utilizza un processore Intel nativo, non emulando un processore ARM. Come per l'emulatore Intel HAX, anche qui C # funziona molto più velocemente. Ecco i miei risultati:

Emulatore Genymotion - Intel (Android 4.1.1, API 16)

Java: tempo totale complessivo (5 esecuzioni): 2069 ms, con totale lettura file: 2248 ms

C #: tempo totale complessivo (5 corse): 1543 ms, con lettura totale del file: 1642 ms

Ho poi notato che c'era un aggiornamento a Xamarin.Android beta, versione 4.7.11, con note di rilascio che menzionavano anche alcune modifiche nel runtime Mono. Ha deciso di testare rapidamente alcuni dispositivi ARM e una grande sorpresa: i numeri C # sono migliorati:

BN Nook XD +, ARM (Android 4.0)

Java: tempo totale complessivo (5 esecuzioni): 8103 ms, con totale lettura file: 8569 ms

C #: tempo totale complessivo (5 corse): 7951 ms, con totale lettura file: 8161 ms

Wow! C # ora è meglio di Java? Ho deciso di ripetere il test sul mio Galaxy Note 2:

Samsung Galaxy Note 2 - ARM (Android 4.1.1)

Java: tempo totale complessivo (5 esecuzioni): 9675 ms, con totale lettura file: 10028 ms

C #: tempo totale complessivo (5 corse): 9911 ms, con lettura totale file: 10104 ms

Qui C # sembra essere solo leggermente più lento, ma questi numeri mi hanno dato una pausa: perché il tempo è più lungo rispetto a Nook HD +, anche se Note 2 ha un processore più veloce? La risposta: modalità di risparmio energetico. In Nook, era disabilitato, in Nota 2 - abilitato. Ha deciso di provare con la modalità di risparmio energetico disabilitata (come abilitata, limita anche la velocità del processore):

Samsung Galaxy Note 2 - ARM (Android 4.1.1), risparmio energetico disabilitato

Java: tempo totale complessivo (5 esecuzioni): 7153 ms, con totale lettura file: 7459 ms

C #: tempo totale complessivo (5 corse): 6906 ms, con totale lettura file: 7070 ms

Ora, sorprendentemente, C # è leggermente più veloce di Java anche sul processore ARM. Grande miglioramento!

Modifica 12 luglio 2013

Sappiamo tutti che nulla batte il codice nativo per la velocità e non ero soddisfatto delle prestazioni del mio divisore di frasi in Java o C #, in particolare che ho bisogno di migliorarlo (e quindi renderlo ancora più lento). Ha deciso di riscriverlo in C ++. Ecco un piccolo (cioè un set di file più piccolo rispetto ai test precedenti, per altri motivi) del confronto tra la velocità nativa e Java sul mio Galaxy Note 2, con la modalità di risparmio energetico disabilitata:

Java: tempo totale complessivo (5 esecuzioni): 3292 ms, con totale lettura file: 3454 ms

Pollice nativo: tempo totale complessivo (5 corse): 537 ms, con lettura totale del file: 657 ms

Braccio nativo: tempo totale complessivo (5 corse): 458 ms, con lettura totale del file: 587 ms

Sembra che per il mio test particolare, il codice nativo sia da 6 a 7 volte più veloce di Java. Avvertenza: impossibile utilizzare la classe std :: regex su Android, quindi ho dovuto scrivere le mie routine specializzate alla ricerca di interruzioni di paragrafo o tag html. I miei test iniziali dello stesso codice su un PC usando regex, erano circa 4-5 volte più veloci di Java.

Accidenti! Risvegliando la memoria grezza con i puntatori char * o wchar *, mi sono sentito subito più giovane di 20 anni! :)

Modifica il 15 luglio 2013

(Vedi di seguito, con modifiche del 30/07/2013, per risultati molto migliori con Dot42)

Con qualche difficoltà, sono riuscito a trasferire i miei test C # su Dot42 (versione 1.0.1.71 beta), un'altra piattaforma C # per Android. I risultati preliminari mostrano che il codice Dot42 è circa 3 volte (3 volte) più lento di Xamarin C # (v. 4.7.11), su un emulatore Intel Android. Un problema è che la classe System.Text.RegularExpressions in Dot42 non ha la funzione Split () che ho usato nei test Xamarin, quindi ho usato invece la classe Java.Util.Regex e Java.Util.Regex.Pattern.Split () , quindi in questo particolare punto del codice c'è questa piccola differenza. Non dovrebbe essere un grosso problema però. Dot42 compila il codice Dalvik (DEX), quindi collabora nativamente con Java su Android, non necessita di interoperazioni costose da C # a Java come Xamarin.

Solo per confronto, eseguo anche il test su dispositivi ARM: qui il codice Dot42 è "solo" 2 volte più lento di Xamarin C #. Ecco i miei risultati:

HTC Nexus One Android 2.3.7 (ARM)

Java: tempo totale complessivo (5 esecuzioni): 12187 ms, con totale lettura file: 13200 ms

Xamarin C #: tempo totale complessivo (5 corse): 13935 ms, con totale lettura file: 14465 ms

Dot42 C #: tempo totale complessivo (5 corse): 26000 ms, con totale lettura file: 27168 ms

Samsung Galaxy Note 2, Android 4.1.1 (ARM)

Java: tempo totale complessivo (5 esecuzioni): 6895 ms, con totale lettura file: 7275 ms

Xamarin C #: tempo totale complessivo (5 corse): 6466 ms, con totale lettura file: 6720 ms

Dot42 C #: tempo totale complessivo (5 corse): 11185 ms, con totale lettura file: 11843 ms

Emulatore Intel, Android 4.2 (x86)

Java: tempo totale complessivo (5 esecuzioni): 2389 ms, con lettura totale del file: 2770 ms

Xamarin C #: tempo totale complessivo (5 corse): 1748 ms, con totale lettura file: 1933 ms

Dot42 C #: tempo totale complessivo (5 corse): 5150 ms, con lettura totale del file: 5459 ms

Per me, è stato anche interessante notare che Xamarin C # è leggermente più veloce di Java su un nuovo dispositivo ARM e leggermente più lento sul vecchio Nexus One. Se qualcuno desidera eseguire anche questi test, per favore fatemelo sapere e aggiornerò i sorgenti su GitHub. Sarebbe particolarmente interessante vedere i risultati da un vero dispositivo Android con processore Intel.

Aggiornamento 26/07/2013

Solo un aggiornamento rapido, ricompilato dalle app di riferimento con l'ultimo Xamarin.Android 4.8 e anche con l'aggiornamento dot42 1.0.1.72 rilasciato oggi - nessuna modifica significativa rispetto ai risultati precedentemente riportati.

Aggiornamento del 30/07/2013 - risultati migliori per dot42

Testato nuovamente Dot42 con la porta di Robert (dai produttori di dot42) del mio codice Java su C #. Nella mia porta C # fatta inizialmente per Xamarin, ho sostituito alcune classi Java native, come ListArray, con la classe List nativa di C #, ecc. Robert non aveva il mio codice sorgente Dot42, quindi lo portò di nuovo da Java e usò le classi Java originali in tali luoghi, che avvantaggia Dot42, immagino perché funziona in Dalvik VM, come Java, e non in Mono, come Xamarin. Ora i risultati di Dot42 sono molto migliori. Ecco un registro dai miei test:

30/07/2013 - Test Dot42 con più classi Java in Dot42 C #

Emulatore Intel, Android 4.2

Dot42, Codice di Greg che utilizza StringBuilder.Replace () (come in Xamarin):
tempo totale complessivo (5 corse): 3646 ms, con lettura totale del file: 3830 ms

Dot42, Codice di Greg che utilizza String.Replace () (come in Java e il codice di Robert):
tempo totale complessivo (5 esecuzioni): 3027 ms, con lettura totale del file: 3206 ms

Dot42, Codice Robert:
tempo totale complessivo (5 corse): 1781 ms, con lettura totale file: 1999 ms

Xamarin:
tempo totale complessivo (5 corse): 1373 ms, con totale lettura file: 1505 ms

Java:
tempo totale complessivo (5 esecuzioni): 1841 ms, con totale lettura file: 2044 ms

ARM, Samsung Galaxy Note 2, risparmio energetico, Android 4.1.1

Dot42, Codice di Greg che utilizza StringBuilder.Replace () (come in Xamarin):
tempo totale complessivo (5 corse): 10875 ms, con lettura totale del file: 11280 ms

Dot42, Codice di Greg che utilizza String.Replace () (come in Java e il codice di Robert):
tempo totale complessivo (5 esecuzioni): 9710 ms, con lettura totale del file: 10097 ms

Dot42, Codice Robert:
tempo totale complessivo (5 corse): 6279 ms, con lettura totale file: 6622 ms

Xamarin:
tempo totale complessivo (5 corse): 6201 ms, con totale lettura file: 6476 ms

Java:
tempo totale complessivo (5 esecuzioni): 7141 ms, con totale lettura file: 7479 ms

Penso ancora che Dot42 abbia ancora molta strada da fare. Avere classi simili a Java (ad es. ArrayList) e una buona prestazione con esse renderebbe il porting del codice da Java a C # leggermente più semplice. Tuttavia, questo è qualcosa che non avrei molte probabilità di fare molto. Preferirei usare il codice C # esistente (librerie, ecc.), Che utilizzerà le classi C # native (ad es. Elenco) e che funzionerebbe lentamente con l'attuale codice dot42 e molto bene con Xamarin.

Greg

Sì, la macchina virtuale Mono di Xamarin è più impressionante di quella di Dalvik di Google utilizzata in Android. L'ho testato con i tablet HTC Flyer e Acer Iconia Tab per confrontare la porta C # di Android tramite Mono contro Java Dalvik, con l'implementazione C # di Android e truccando davvero il Dalvik basato su Java.

I came across this interesting post

https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.kfbauchtz

Spero che queste informazioni siano d'aiuto.

Di recente abbiamo esaminato l'utilizzo di Xamarin per un'app. Abbiamo utilizzato il codice C # che avevamo già scritto per la versione di Windows RT della nostra app. Alcuni dettagli specifici hanno dovuto essere riscritti per la versione Android.

Ciò che abbiamo scoperto è che l'I / O in Xamarin C # è circa 2 volte più lento di Java. La nostra app è fortemente legata all'I / O. Non ne abbiamo ancora scoperto la causa, ma al momento stiamo assumendo che sia dovuto al marshalling. Mentre proviamo a rimanere nella Mono VM per la maggior parte del tempo, non sappiamo come Mono acceda effettivamente al disco.

Sta anche dicendo che il nostro codice C # utilizza SQLite.NET ( https://github.com/praeclarum/sqlite-net ). Anche i recuperi identici che utilizzano il codice SQLite.NET sono 2 volte più lenti rispetto all'utilizzo del wrapper Java SQLite di Android. Dopo aver esaminato il codice sorgente, sembra associarsi direttamente alla DLL, quindi non so perché sia ​​molto più lento. Una possibilità è che le stringhe di marshalling da native a Java possano essere più veloci su Android rispetto a native su C # sia su Xamarin.

Questo è un altro post sul blog più aggiornato che vorrei condividere con te . Paragona Xamarin al codice nativo e Cordova sia su IO che su Android.

In breve, Xamarin si comporta talvolta meglio del codice nativo. Ha testato le dimensioni dell'app, i tempi di caricamento, il caricamento di un elenco dal servizio Azure e il calcolo del numero primo.

Godere!

Modifica: ho aggiornato il link non funzionante e ho notato che esiste una parte 2

Ecco alcune informazioni che ho trovato in un altro test tra le soluzioni native, Xamarin e Xamarin.Forms (i test includono anche le prestazioni iOS) sui due seguenti dispositivi:

Samsung Galaxy A7 : versione del sistema operativo Android: 6.0 Unità centrale di elaborazione: RAM Octa-core 1.9 GHz Cortex-A53: 3GB Risoluzione del display: 1920 × 1080

iPhone 6s : versione iOS: 10.3.3 Unità centrale: Dual-core 1,84 GHz Twister RAM: 2 GB Risoluzione display: 1334 × 750

Il confronto viene effettuato su alcune funzionalità comuni, ognuna con la propria applicazione:

- Basic “Hello World”
- REST API
- JSON Serialization/Deserialization
- Photo Loading
- SQL Database Insert and Get All

Ogni test viene ripetuto più volte, i grafici mostrano i risultati medi.

Ciao mondo

API di riposo

Insieme di test volti a misurare il tempo impiegato dall'app per inviare una richiesta tramite l'API REST e ricevere la risposta senza ulteriore elaborazione dei dati, utilizzando l'API OpenWeatherMap.

Test delle operazioni JSON realizzati utilizzando il framework Json.net di Newtonsoft per serializzare e deserializzare gli oggetti JSON in tutte le app Xamarin. La serializzazione e la deserializzazione native di Android sono state testate utilizzando due librerie Java: Jackson e GSON.

Vengono eseguite due corse, una prima da zero e una seconda con informazioni e operazioni memorizzate nella cache

Prima corsa :

(Native iOS JSON Operations sta uccidendo questo test tra l'altro, e Xamarin lo unisce nel secondo)

Operazioni fotografiche

Primo caricamento su immagini con tre diverse risoluzioni:

Resolution – 858×569, Size – 868Kb
Resolution – 2575×1709, Size – 8Mb
Resolution – 4291×2848, Size – 28.9Mb

Qualcosa sembrava incerto su Xamarin.Forms risultati per questo test, quindi non è incluso nel grafico.

Operazioni SQLite

Due operazioni testate:

BulkInsert: Loading rows of data into a database table.
GetAll: Retrieving all data from the database.

Con database con 10.000 record. Tutte le operazioni sono state elaborate internamente sui dispositivi.

Xamarin Native (Xamarin.iOS / Xamarin.Android) si presentano come piuttosto buone alternative al codice nativo, mentre Xamarin.Forms sembra lento in molti casi, ma può essere davvero un'ottima soluzione per sviluppare applicazioni davvero semplici in modo rapido.

Il test completo proviene da questa fonte:

https://www.altexsoft.com/blog/engineering/performance-comparison-xamarin-forms-xamarin-ios-xamarin-android-vs-android-and-ios-native-applications/

Grazie per avermi dato le spiegazioni per migliorare la mia risposta, spero che questo aiuti un po ':)

Prestazione

Performance è una parola vaga se non si definisce ciò che si intende per performance, se si tratta di prestazioni di calcolo semplici Xamarin può essere più veloce di Java a seconda della natura del calcolo.

Android viene fornito con moduli multipe per eseguire il codice in:

• RenderScript (CPU e GPU)
• Java (SDK)
• C ++ (NDK)
• OpenGL (GPU)

È abbastanza ovvio che quando si esegue il codice più nativa è la soluzione, più veloce sarà. Un linguaggio basato sul runtime non batterà mai un linguaggio che gira direttamente sulla CPU.

D'altra parte, se si desidera misurare le prestazioni di utilizzo nella vita reale, Java è propbaby più veloce di Xamarin.

Xamarin e perché può essere più lento

Quando si confronta Xamarin con semplici vecchie applicazioni Java, le prestazioni possono essere molto più veloci per Xamarin in quanto possono essere più lente.

In un esempio reale, è molto probabile che le applicazioni Xamarin siano più lente delle applicazioni Java poiché molte chiamate Android / Java (di sistema) devono essere delegate da e verso il runtime di Xamarin usando i cosiddetti bind.

Esistono alcuni tipi diversi di attacchi che è importante sapere:

• JNI (Java Native Interface): l'associazione utilizzata in molte applicazioni Android per interfacciarsi tra codice Java (SDK) e codice C ++ nativo (NDK).
• MCW (Managed Callable Wrappers): un'associazione disponibile in Xamarin per interfacciarsi dal codice C # gestito al codice Java (runtime Android).
• ACW (Android Callable Wrappers): un'associazione disponibile in Xamarin per l'interfaccia dal codice Java (runtime Android) al codice C # gestito.

Maggiori informazioni su MCW e ACW qui: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/

Gli attacchi sono in termini di prestazioni molto molto costosi. Invocare un metodo C ++ da Java aggiunge un enorme sovraccarico nel tempo di chiamata, chiamare un metodo C ++ dall'interno di C ++ è molte molte volte più veloce.

Qualcuno ha eseguito un test delle prestazioni per calcolare quante operazioni Java in media costa una chiamata JNI: Qual è il sovraccarico quantitativo di effettuare una chiamata JNI?

Ma non solo le chiamate JNI sono costose, così come le chiamate da e verso MCW e ACW. Le applicazioni Xamarin del mondo reale effettuano molte chiamate utilizzando i collegamenti e, a causa di questo mondo reale, l'utilizzo di un'applicazione Xamarin può essere (e sarà in generale) più lento di una semplice vecchia applicazione Java. Tuttavia, a seconda di come è stata progettata l'applicazione Xamarin, è molto probabile che l'utente non noterà nemmeno la differenza.

TLDR / Conclusione: Xamarin deve utilizzare ogni sorta di attacchi, che sono costosi in termini di tempo.

Oltre ai binding, ci sono molti altri fattori coinvolti quando si parla di prestazioni del mondo reale, ad esempio: dimensioni del file binario, caricamento dell'app in memoria, operazioni di I / O e molti altri. Un post sul blog che indaga su alcune di queste cose può essere trovato qui: https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms

Sono test piuttosto vecchi ma potrebbero essere rilevanti: https://github.com/EgorBo/Xamarin.Android-vs-Java

Test aritmetico

Collezioni, generici, tipi di valore personalizzati

Lavorare con le stringhe

UPD: nuovi dati con Google Pixel 2 (grazie yousha-aleayoub )