Qualcuno ha parametri di riferimento (codice & risultati) che confronta le performance delle applicazioni Android scritte in Xamarin C # e Java?

Ho incontrato Xamarin afferma che la loro implementazione Mono su Android e le loro applicazioni compilate in C # sono più veloci del codice Java. Qualcuno ha eseguito benchmark effettivi su codice Java e C # molto simili su diverse piattaforms Android per verificare tali rivendicazioni, potrebbe submit il codice e i risultati?

Aggiunto 18 giugno 2013

Dal momento che non c'era risposta e non riusciva a trovare tali benchmark fatta da altri, ha deciso di fare i miei test. Purtroppo la mia domanda rimane "bloccata", quindi non posso submit questa risposta come risposta, solo modificare la domanda. Voglia votare per riaprire la domanda. Per C #, ho usato Xamarin.Android ver. 4.7.09001 (beta). Il codice sorgente, tutti i dati utilizzati per il test e i pacchetti APK compilati sono in GitHub:

  • Seek Bar thumb non trasparente in Android 5.0 API 21 Lollipop
  • Android: Ottenere l'orientamento (paesaggio / ritratto) sul lancio di attività
  • Imansible risolvere Eclipse "Archivio per la libreria richiesta ..."
  • Servizio di avvio di Android NFC
  • Errore: la revisione di Strumenti per la creazione di SDK (23.0.3) è troppo bassa per il progetto ': app'. Il minimo richiesto è 25.0.0
  • Android: View.getTag / setTag e IllegalArgumentException
  • Java: https://github.com/gregko/TtsSetup_Java

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

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

    Risultati dai miei test

    Ho portto la class di estrazione della mia frase in C # (dall'applicazione @Voice Aloud Reader) e ho eseguito test su 10 file html in lingua inglese, russo, francese, polacca e ceca. Ogni esecuzione è stata eseguita 5 volte su tutti e 10 i file e il tempo totale per 3 dispositivi diversi e un emulatore sono riportti di seguito. Ho testato la versione "Release" solo, senza il debug abilitato.

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

    Java: Grand Total Time (5 run): 12361 ms, con totale lettura file: 13304 ms

    C #: Grand Total Time (5 corse): 17504 ms, con totale lettura file: 17956 ms

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

    Java: Grand Total Time (5 run): 8947 ms, con totale lettura file: 9186 ms

    C #: Grand Total Time (5 corse): 9884 ms, con totale lettura file: 10247 ms

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

    Java: Grand Total Time (5 run): 9742 ms, con totale lettura file: 10111 ms

    C #: Grand Total Time (5 corse): 10459 ms, con totale lettura di file: 10696 ms

    Emulatore – Intel (Android 4.2, API 17)

    Java: Grand Total Time (5 run): 2699 ms, con totale lettura file: 3127 ms

    C #: Grand Total Time (5 run): 2049 ms, con totale lettura file: 2182 ms

    Emulatore – Intel (Android 2.3.7, API 10)

    Java: Grand Total Time (5 run): 2992 ms, con totale lettura file: 3591 ms

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

    Emulatore – Arm (Android 4.0.4, API 15)

    Java: Grand Total Time (5 corse): 41751 ms, con totale lettura file: 43866 ms

    C #: Grand Total Time (5 run): 44136 ms, con totale lettura file: 45109 ms

    Breve discussione

    Il mio codice di prova contiene principalmente analisi di text, sostituzione e ricerche di Regex, forse per altri codici (ad esempio più operazioni numbersche) i risultati sarebbero diversi. Su tutti i dispositivi con processri ARM, Java ha eseguito meglio il codice Xamarin C #. La differenza più grande era sotto Android 2.3, where il codice C # funziona a ca. 70% della velocità Java.

    Su emulatore Intel (con tecnologia Intel HAX, l'emulatore viene eseguito in modalità vel virt), il codice Xamarin C # esegue il codice di esempio molto più veloce di Java – circa 1,35 volte più veloce. Forse il codice macchina e le librerie virtuali Mono sono molto meglio ottimizzate su Intel che su ARM?

    Modifica 8 luglio 2013

    Ho appena installato l'emulatore Android Genymotion, che viene eseguito in Oracle VirtualBox e ancora questo utilizza un processre Intel originale, non emulando il processre ARM. Come per l'emulatore Intel HAX, C # corre qui molto più velocemente. Ecco i miei risultati:

    Emulator di Genymotion – Intel (Android 4.1.1, API 16)

    Java: Grand Total Time (5 corse): 2069 ms, con totale lettura file: 2248 ms

    C #: Grand Total Time (5 corse): 1543 ms, con totale lettura di file: 1642 ms

    Ho poi notato che c'è stato un aggiornamento a Xamarin.Android beta, versione 4.7.11, con note di rilascio che menzionano alcune modifiche anche in runtime Mono. Ha deciso di testare rapidamente alcuni dispositivi ARM e la grande sorpresa – i numbers C # migliorati:

    BN Nook XD +, ARM (Android 4.0)

    Java: Grand Total Time (5 run): 8103 ms, con totale lettura file: 8569 ms

    C #: Grandissimo tempo totale (5 run): 7951 ms, con totale lettura file: 8161 ms

    Wow! C # è ora migliore di Java? Deciduto di ripetere la prova sulla mia Galaxy Nota 2:

    Samsung Galaxy Note 2 – ARM (Android 4.1.1)

    Java: Grand Total Time (5 run): 9675 ms, con totale lettura file: 10028 ms

    C #: Grand Total Time (5 corse): 9911 ms, con totale lettura file: 10104 ms

    Qui C # sembra essere solo leggermente più lento, ma questi numbers mi hanno dato una pausa: perché il tempo è più lungo che su Nook HD +, anche se la nota 2 ha un processre più veloce? La risposta: modalità di risparmio energetico. Su Nook, è stato distriggersto, nella nota 2 – abilitata. Ha deciso di provare con modalità di risparmio energetico disabilitato (come abilitato, limita anche la velocità del processre):

    Samsung Galaxy Note 2 – ARM (Android 4.1.1), il risparmio energetico è disabilitato

    Java: Grand Total Time (5 run): 7153 ms, con totale lettura file: 7459 ms

    C #: Grand Total Time (5 corse): 6906 ms, con totale lettura di file: 7070 ms

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

    Modifica 12 luglio 2013

    Sappiamo tutti, che nulla batte il codice nativo per la velocità e non sono stato soddisfatto delle performance della mia divisione di righe in Java o in C #, in particolare che ho bisogno di migliorarla (e quindi renderla ancora più lenta). Decideva di ri-scrivere in C ++. Ecco un piccolo (cioè un insieme di file più piccolo rispetto ai precedenti test, per altri motivi) confronto della velocità di nativo vs Java sulla mia nota Galaxy 2, con modalità di risparmio energetico disabilitato:

    Java: Grand Total Time (5 run): 3292 ms, con totale lettura file: 3454 ms

    Native thumb: Grand Total Time (5 corse): 537 ms, con totale lettura di file: 657 ms

    Braccio nativo: Grand Total Time (5 corse): 458 ms, con lettura totale di file: 587 ms

    Sembra per il mio test particolare, il codice nativo è 6 a 7 volte più veloce di Java. Caveat: non poteva usare la class std :: regex su Android, quindi wherevo scrivere le mie routine specializzate in cerca di pause di paragrafi o tag html. Le mie prime prove dello stesso codice su un PC con regex erano circa 4-5 volte più veloci di Java.

    Accidenti! Svegliando la memory raw con char * o wchar * puntatori di nuovo, mi sentivo istantaneamente 20 anni più giovane! 🙂

    Modifica 15 luglio 2013

    (Vedi sotto, con le modifiche del 7/30/2013, per risultati molto migliori con Dot42)

    Con una certa difficoltà ho mangiato per portre i miei test C # a Dot42 (beta versione 1.0.1.71), un'altra piattaforma C # per Android. I risultati preliminari mostrano che il codice Dot42 è circa 3x (3 volte) più lento di Xamarin C # (v. 4.7.11), su un emulatore Android Intel. Un problema è che la class System.Text.RegularExpressions in Dot42 non disponga della function Split () che ho usato nei test di Xamarin, quindi ho usato Java.Util.Regex e invece Java.Util.Regex.Pattern.Split ( ), quindi in questo particolare posto nel codice c'è questa piccola differenza. Non dovrebbe essere un grosso problema però. Dot42 compila il codice Dalvik (DEX), quindi collabora con Java sul Android nativamente, non richiede costose integerp da C # a Java come Xamarin.

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

    HTC Nexus One Android 2.3.7 (ARM)

    Java: Grand Total Time (5 run): 12187 ms, con totale lettura file: 13200 ms

    Xamarin C #: Grand Total Time (5 corse): 13935 ms, con totale lettura file: 14465 ms

    Dot42 C #: Grand Total Time (5 corse): 26000 ms, con totale lettura file: 27168 ms

    Samsung Galaxy Note 2, Android 4.1.1 (ARM)

    Java: Grand Total Time (5 run): 6895 ms, con totale lettura file: 7275 ms

    Xamarin C #: Grand Total Time (5 corse): 6466 ms, con totale lettura file: 6720 ms

    Dot42 C #: Grand Total Time (5 run): 11185 ms, con totale lettura file: 11843 ms

    Emulatore Intel, Android 4.2 (x86)

    Java: Grand Total Time (5 run): 2389 ms, con totale lettura file: 2770 ms

    Xamarin C #: Grand Total Time (5 corse): 1748 ms, con totale lettura di file: 1933 ms

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

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

    Aggiornato il 26/07/2013

    Solo un aggiornamento rapido, rielaborato da applicazioni di benchmark con l'ultima versione Xamarin.Android 4.8 e anche con aggiornamento dot42 1.0.1.72 pubblicato oggi – nessun cambiamento significativo dai risultati riportti prima.

    Aggiornamento 7/30/2013 – migliori risultati per dot42

    Dot42 riesaminato con la port di Robert (da dot42 maker) del mio codice Java a C #. Nella mia port C # iniziata per Xamarin, ho sostituito alcune classi Java nativo, come ListArray, con classi di class native a C #, ecc. Robert non ha avuto il mio codice sorgente Dot42, quindi lo ha portto di nuovo da Java e ha usato le classi Java originali tali luoghi, che beneficiano di Dot42, immagino perché funziona in Dalvik VM, come Java, e non in Mono, come Xamarin. Ora i risultati Dot42 sono molto migliori. Ecco un registro dal mio test:

    7/30/2013 – Test Dot42 con più classi Java in Dot42 C #

    Emulatore Intel, Android 4.2

    Dot42, Greg's Code usando StringBuilder.Replace () (come in Xamarin):
    Grand total time (5 corse): 3646 ms, con totale lettura file: 3830 ms

    Dot42, Greg's Code usando String.Replace () (come nel codice Java e Robert):
    Grand total time (5 corse): 3027 ms, con totale lettura file: 3206 ms

    Dot42, il codice di Robert:
    Grandissimo tempo totale (5 run): 1781 ms, con totale lettura file: 1999 ms

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

    Giava:
    Grand total time (5 run): 1841 ms, con totale lettura file: 2044 ms

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

    Dot42, Greg's Code usando StringBuilder.Replace () (come in Xamarin):
    Grandissimo tempo totale (5 corse): 10875 ms, con totale lettura file: 11280 ms

    Dot42, Greg's Code usando String.Replace () (come nel codice Java e Robert):
    Grandissimo tempo totale (5 corse): 9710 ms, con totale lettura file: 10097 ms

    Dot42, il codice di Robert:
    Grand total time (5 corse): 6279 ms, con totale lettura file: 6622 ms

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

    Giava:
    Grandissimo tempo totale (5 corse): 7141 ms, con totale lettura file: 7479 ms

    Penso ancora che Dot42 abbia un lungo cammino da percorrere. Avere lezioni simili a Java (es. ArrayList) e una buona prestazione con loro, avrebbe reso il codice di port da Java a C # leggermente più facile. Tuttavia, questo è qualcosa che non avrei potuto fare molto. Vorrei preferire utilizzare codice C # esistente (librerie, ecc.), Che utilizzerà classi native C # (es. Elenco) e che eseguirebbe lentamente con il codice attuale dot42 e molto bene con Xamarin.

    Greg

  • Connettere Mongo DB con l'applicazione Android
  • Quali Responsabili di Android -sw # dp vs -w # dp
  • Perché sto ottenendo android.os.NetworkOnMainThreadException con AsyncTask?
  • mostrare dati dal database all'elenco Android
  • Testo del button di allineamento del centro a sinistra
  • Quando si utilizza TalkBack, quale è il modo preferito per avvisare l'utente quando il contenuto di un TextView è stato modificato?
  • 4 Solutions collect form web for “Qualcuno ha parametri di riferimento (codice & risultati) che confronta le performance delle applicazioni Android scritte in Xamarin C # e Java?”

    Sì, la macchina virtuale Mono di Xamarin è più impressionante di Google Dalvik usata in Android. Ho testato con le compresse HTC Flyer e Acer Iconia Tab per confrontare la port C # di Android tramite Mono contro Java Dalvik, con l'implementazione di Android di Android e con successo il Dalvik basato su Java.

    I came across this interesting post 

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

    Applicazione di Android App

    iOS App Performance

    Spero che queste informazioni aiutino.

    Questo è un altro blog post più aggiornato che vorrei condividere con te . Confronta Xamarin con il codice nativo e Cordova su entrambi iOS e Android.

    In poche parole, Xamarin esegue talvolta meglio del codice nativo. Ha testato la dimensione dell'applicazione, i tempi di caricamento, il caricamento di un elenco dal servizio Azure e dal calcolo delle prime cifre.

    Godere!

    Modifica: ho aggiornato il collegamento morto e ho notato che c'è una parte 2

    Recentemente abbiamo indagato utilizzando Xamarin per un'app. Abbiamo utilizzato il codice C # che abbiamo già scritto per la versione di Windows RT della nostra applicazione. Alcuni dettagli specifici wherevano essere riscritti per la versione Android.

    Ciò che abbiamo scoperto è che l'I / O in Xamarin C # è circa 2x più lento di Java. La nostra app è molto legata all'I / O. Non abbiamo ancora scoperto la causa di questo, ma al momento pensiamo che sia dovuto alla marshalling. Mentre cerchiamo di rimanere all'interno del Mono VM per la maggior parte del tempo, non sappiamo come Mono effettivamente accede al disco.

    Dice anche che il nostro codice C # usa SQLite.NET ( https://github.com/praeclarum/sqlite-net ). I rilievi identici usando il codice SQLite.NET sono anche più lenti di quanto utilizzi il wrapper Java SQLite di Android. Dopo aver esaminato il codice sorgente, sembra legarsi direttamente al C.dll, quindi non so perché è molto più lento. Una possibilità è che le stringhe di marshalling da nativo a Java possono essere più veloci su Android che nativo di C # è su Xamarin.

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.