Question Quelqu'un at-il des benchmarks (code et résultats) comparant les performances des applications Android écrites en Xamarin C # et Java? [fermé]


Je suis tombé sur Xamarin affirme que leur implémentation Mono sur Android et leurs applications compilées C # sont plus rapides que le code Java. Quelqu'un a-t-il effectué des tests sur des codes Java et C # très similaires sur différentes plates-formes Android afin de vérifier ces affirmations, pourrait-il publier le code et les résultats?

Ajouté le 18 juin 2013

Comme il n'y avait pas de réponse et ne pouvait pas trouver de tels repères effectués par d'autres, a décidé de faire mes propres tests. Malheureusement, ma question reste "verrouillée" donc je ne peux pas la poster comme réponse, seulement éditer la question. Veuillez voter pour rouvrir cette question. Pour C #, j'ai utilisé Xamarin.Android ver. 4.7.09001 (bêta). Le code source, toutes les données que j'ai utilisées pour tester et les paquets APK compilés sont sur GitHub:

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

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

Si quelqu'un souhaite répéter mes tests sur d'autres appareils ou émulateurs, je serais intéressé d'apprendre les résultats.

Résultats de mes tests

J'ai porté ma classe d'extracteur de phrases sur C # (depuis mon application @Voice Aloud Reader) et j'ai effectué des tests sur 10 fichiers html en anglais, russe, français, polonais et tchèque. Chaque exécution a été effectuée 5 fois sur les 10 fichiers, et le temps total pour 3 appareils différents et un émulateur est affiché ci-dessous. J'ai testé les versions "Release" uniquement, sans débogage activé.

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

Java: Grand temps total (5 séries): 12361 ms, avec un total de lecture de fichier: 13304 ms

C #: Grand temps total (5 séries): 17504 ms, avec un total de lecture de fichier: 17956 ms

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

Java: Grand temps total (5 séries): 8947 ms, avec un total de lecture de fichier: 9186 ms

C #: Grand temps total (5 passages): 9884 ms, avec un total de lecture de fichier: 10247 ms

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

Java: Grand temps total (5 séries): 9742 ms, avec un total de lecture de fichier: 10111 ms

C #: Grand temps total (5 séries): 10459 ms, avec un total de lecture de fichier: 10696 ms

Emulateur - Intel (Android 4.2, API 17)

Java: Grand temps total (5 séries): 2699 ms, avec un total de lecture de fichier: 3127 ms

C #: Grand temps total (5 séries): 2049 ms, avec un total de lecture de fichier: 2182 ms

Emulateur - Intel (Android 2.3.7, API 10)

Java: Grand temps total (5 séries): 2992 ms, avec un total de lecture de fichier: 3591 ms

C #: Grand temps total (5 séries): 2049 ms, avec un total de lecture de fichier: 2257 ms

Emulator - Arm (Android 4.0.4, API 15)

Java: Grand temps total (5 séries): 41751 ms, avec un total de lecture de fichier: 43866 ms

C #: Grand temps total (5 passages): 44136 ms, avec un total de lecture de fichier: 45109 ms

Brève discussion

Mon code de test contient principalement l'analyse de texte, le remplacement et les recherches Regex, peut-être pour d'autres codes (par exemple des opérations plus numériques), les résultats seraient différents. Sur tous les appareils dotés de processeurs ARM, Java fonctionnait mieux que le code Xamarin C #. La plus grande différence était sous Android 2.3, où le code C # fonctionne à env. 70% de la vitesse Java.

Sur l'émulateur Intel (avec la technologie Intel HAX, l'émulateur fonctionne en mode virt rapide), le code Xamarin C # exécute mon code d'exemple beaucoup plus rapidement que Java - environ 1,35 fois plus vite. Peut-être que le code de la machine virtuelle Mono et les bibliothèques sont bien mieux optimisés sur Intel que sur ARM?

Modifier le 8 juillet 2013

Je viens d'installer l'émulateur Genymotion Android, qui fonctionne dans Oracle VirtualBox, et encore celui-ci utilise un processeur Intel natif, n'émulant pas le processeur ARM. Comme avec l'émulateur Intel HAX, encore une fois, C # s'exécute beaucoup plus rapidement. Voici mes résultats:

Emulateur Genymotion - Intel (Android 4.1.1, API 16)

Java:   Grand temps total (5 séries): 2069 ms, avec un total de lecture de fichier: 2248 ms

C #:   Grand temps total (5 séries): 1543 ms, avec un total de lecture de fichier: 1642 ms

J'ai ensuite remarqué qu'il y avait une mise à jour vers la version bêta de Xamarin.Android, version 4.7.11, avec des notes de publication mentionnant également certains changements dans le runtime Mono. Décidé de tester rapidement certains appareils ARM, et grande surprise - les numéros C # améliorés:

BN Nook XD +, ARM (Android 4.0)

Java: durée totale maximale (5 exécutions): 8103 ms, avec lecture du fichier total: 8569 ms

C #: Durée totale totale (5 exécutions): 7951 ms, avec lecture totale du fichier: 8161 ms

Hou la la! C # est maintenant mieux que Java? Décidé de répéter le test sur mon Galaxy Note 2:

Samsung Galaxy Note 2 - ARM (Android 4.1.1)

Java: durée totale maximale (5 exécutions): 9675 ms, avec lecture totale du fichier: 10028 ms

C #: Grand temps total (5 séries): 9911 ms, avec un total de lecture de fichier: 10104 ms

Ici C # ne semble être que légèrement plus lent, mais ces chiffres m'ont fait une pause: Pourquoi le temps est plus long que sur Nook HD +, même si la note 2 a un processeur plus rapide? La réponse: le mode économie d'énergie. Sur Nook, il a été désactivé, Note 2 - activé. Décidé de tester avec le mode d'économie d'énergie désactivé (comme avec activé, il limite également la vitesse du processeur):

Samsung Galaxy Note 2 - ARM (Android 4.1.1), économie d'énergie désactivée

Java: Grand temps total (5 séries): 7153 ms, avec un total de lecture de fichier: 7459 ms

C #: Grand temps total (5 passages): 6906 ms, avec un total de lecture de fichier: 7070 ms

Maintenant, étonnamment, C # est aussi légèrement plus rapide que Java sur le processeur ARM. Grande amélioration!

Modifier le 12 juillet 2013

Nous savons tous que rien ne bat le code natif pour la vitesse, et je n'ai pas été satisfait de la performance de mon séparateur de phrases en Java ou C #, en particulier que j'ai besoin de l'améliorer (et donc de le ralentir). Décidé de le ré-écrire en C ++. Voici un petit (c'est-à-dire un plus petit ensemble de fichiers que les tests précédents, pour d'autres raisons) comparaison de la vitesse de native vs Java sur mon Galaxy Note 2, avec le mode économie d'énergie désactivé:

Java: Grand temps total (5 passages): 3292 ms, avec un total de lecture de fichier: 3454 ms

Pouce natif: Grand temps total (5 passages): 537 ms, avec un total de lecture de fichier: 657 ms

Bras natif: Grand temps total (5 séries): 458 ms, avec un total de lecture de fichier: 587 ms

On dirait que pour mon test particulier, le code natif est 6 à 7 fois plus rapide que Java. Attention: ne pouvait pas utiliser la classe std :: regex sur Android, alors j'ai dû écrire mes propres routines spécialisées pour rechercher des sauts de paragraphes ou des balises HTML. Mes premiers tests du même code sur un PC utilisant regex étaient environ 4 à 5 fois plus rapides que Java.

Phew! En réveillant la mémoire brute avec des pointeurs de char * ou de wchar *, je me sentais instantanément plus jeune de 20 ans! :)

Modifier le 15 juillet 2013

(Voir ci-dessous, avec modifications du 30/07/2013, pour de meilleurs résultats avec Dot42)


487
2018-06-16 15:50


origine


Réponses:


Oui, la machine virtuelle Mono de Xamarin est plus impressionnante que Dalvik de Google utilisée dans Android. Je l'ai testé avec les tablettes HTC Flyer et Acer Iconia Tab pour comparer le port C # d'Android à Mono contre Java Dalvik, avec l'implémentation C # d'Android et le véritable déblocage de Dalvik basé sur Java.


56



I came across this interesting post

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

Android App Performance

iOS App Performance

J'espère que cette information aide.


34



Ceci est un autre article de blog plus actualisé que j'aimerais partager avec vous. Il compare Xamarin au code natif et à Cordova sur IOs et Android.

En bref, Xamarin fonctionne parfois mieux que le code natif. Il a testé la taille de l'application, les temps de chargement, le chargement d'une liste à partir du service Azure et le calcul des nombres premiers.

Prendre plaisir!

Edit: J'ai mis à jour le lien mort et j'ai remarqué que il y a une partie 2


30



Nous avons récemment étudié l'utilisation de Xamarin pour une application. Nous avons utilisé le code C # que nous avions déjà écrit pour la version Windows RT de notre application. Certains détails spécifiques devaient être réécrits pour la version Android.

Nous avons découvert que les E / S dans Xamarin C # sont environ 2 fois plus lentes que Java. Notre application est fortement liée aux E / S. Nous n'en avons pas encore découvert la cause, mais pour l'instant, nous supposons que cela est dû au marshaling. Bien que nous essayions de rester à l'intérieur du Mono VM la plupart du temps, nous ne savons pas comment Mono accède réellement au disque.

Cela dit aussi que notre code C # utilise SQLite.NET (https://github.com/praeclarum/sqlite-net). Les extractions identiques utilisant le code SQLite.NET sont également 2 fois plus lentes que l'utilisation du wrapper Java SQLite d'Android. Après avoir regardé le code source, il semble se lier directement au C .dll, donc je ne sais pas pourquoi c'est beaucoup plus lent. Une possibilité est que marshaling chaînes de natif à Java peut être plus rapide sur Android que natif à C # est sur Xamarin.


29



Voici quelques informations que j'ai trouvées dans un autre test entre les solutions natives, Xamarin et Xamarin.Forms (les tests incluent également les performances iOS) sur les deux appareils suivants:

Samsung Galaxy A7:     Version du système d'exploitation Android: 6.0     Unité centrale: Octa-core 1,9 GHz Cortex-A53     RAM: 3 Go     Résolution d'affichage: 1920 × 1080

iPhone 6s:     Version iOS: 10.3.3     Unité centrale de traitement: Twister double cœur à 1,84 GHz     RAM: 2 Go     Résolution d'affichage: 1334 × 750

La comparaison est faite sur quelques caractéristiques communes, chacune avec sa propre application:

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

Chaque test est répété plusieurs fois, les graphiques montrent les résultats moyens.


Bonjour le monde

Basic Hellow World performance comparison


API de repos

Ensemble de tests visant à mesurer le temps nécessaire à l'application pour envoyer une demande via l'API REST et recevoir la réponse sans traitement supplémentaire, à l'aide de l'API OpenWeatherMap.

Rest API performance comparison


Opérations JSON Tests réalisés avec le framework Newtonsoft Json.net pour sérialiser et désérialiser les objets JSON dans toutes les applications Xamarin. Sérialisation et désérialisation Android natives testées à l'aide de deux bibliothèques Java: Jackson et GSON.

Deux séries sont réalisées, une première à partir de zéro et une seconde avec des infos et des opérations mises en cache

Première exécution :

JSON serialization first run

JSON deserialization first run

(Opérations natives iOS JSON est en train de tuer ce test btw, et Xamarin le rejoint dans le second)

JSON Serialization second run

JSON Deserialization second run


Opérations photo

Première charge sur les images avec trois résolutions différentes:

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

Image First Load Android

Image First Load iOS

Quelque chose semblait incertain quant aux résultats de Xamarin.Forms pour ce test, il n'est donc pas inclus dans le graphique.


Opérations SQLite

Deux opérations testées:

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

Avec des bases de données ayant 10 000 enregistrements. Toutes les opérations ont été traitées en interne sur les périphériques.

SQLite Android performances

SQLite iOS performances


Xamarin Native (Xamarin.iOS / Xamarin.Android) se présente comme d'assez bonnes alternatives au code natif, alors que Xamarin.Forms semble lent dans beaucoup de cas, mais il peut être une très bonne solution pour développer des applications vraiment simples rapidement.

Le test complet provient de cette source:

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

Merci de me donner les explications pour améliorer ma réponse, j'espère que ça aide un peu :)


6



Performance

La performance est un mot vague si vous ne définissez pas ce que vous entendez par performance, si la performance de calcul est simple, Xamarin peut être plus rapide que Java en fonction de la nature du calcul.

Android vient nativly avec des formes multipour exécuter du code dans:

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

Il est tout à fait évident que lors de l'exécution du code, plus la solution native est rapide, plus elle sera rapide. Un langage basé sur l'exécution ne battra jamais un langage qui s'exécute directement sur le processeur.

Mais d'un autre côté, si vous voulez mesurer les performances d'utilisation de la vie réelle, Java sera plus rapide que Xamarin.

Xamarin et pourquoi il peut être plus lent

Lorsque vous comparez Xamarin à de vieilles applications Java, les performances peuvent être plus rapides pour Xamarin, car elles peuvent être plus lentes.

Dans un exemple réel, les applications Xamarin sont très probablement plus lentes que les applications Java, car de nombreux appels Android / Java (système) doivent être délégués depuis et vers l'exécution Xamarin en utilisant ce que l'on appelle des liaisons.

Il existe plusieurs types de liaisons qu'il est important de connaître:

  • JNI (Java Native Interface): La liaison utilisée dans de nombreuses applications Android pour l'interface entre le code Java (SDK) et le code C ++ natif (NDK).
  • MCW (Wrappers Callable Callable): Une liaison disponible dans Xamarin pour s'interfacer du code C # géré au code Java (exécution Android).
  • ACW (Android Callable Wrappers): Une liaison disponible dans Xamarin pour s'interfacer du code Java (exécution Android) au code C # géré.

Plus sur MCW et ACW ici: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/

Les liaisons sont très coûteuses en termes de performance. Invoquer une méthode C ++ à partir de Java ajoute une énorme charge au temps d’appel, appeler une méthode C ++ depuis C ++ est beaucoup plus rapide.

Quelqu'un a fait un test de performance pour calculer combien d'opérations Java coûtent en moyenne un appel JNI: Quel est le surcoût quantitatif associé à un appel JNI?

Mais les appels JNI ne sont pas les seuls coûteux, de même que les appels vers et depuis MCW et ACW. Les applications Xamarin du monde réel effectuent de nombreux appels à l'aide de liaisons et, à cause de cela, l'utilisation d'une application Xamarin dans le monde réel peut être (et sera en général) plus lente qu'une simple application Java. Toutefois, selon la conception de l'application Xamarin, il est fort probable que l'utilisateur ne remarquera même pas la différence.

TLDR / Conclusion: Xamarin a besoin d'utiliser des sortes de liaisons, qui coûtent beaucoup de temps.

Outre les liaisons, de nombreux autres facteurs interviennent lorsque l'on parle de performances réelles, par exemple: taille du fichier binaire, chargement de l'application en mémoire, opérations d'E / S et bien d'autres. Un billet de blog qui explore certaines de ces choses peut être trouvé ici: https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms


3



C'est assez vieux tests mais pourrait être pertinent: https://github.com/EgorBo/Xamarin.Android-vs-Java

Test arithmétique

enter image description here

Collections, génériques, types de valeur personnalisés

enter image description here

Travailler avec des chaînes

enter image description here

UPD: nouvelles données avec Google Pixel 2 (merci Yousha-Aleayoub)

Pixel 2 tests


0