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




xamarin vs qt mobile (6)

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 benchmarks réels sur des codes Java et C # très similaires sur différentes plates-formes Android pour vérifier ces affirmations, pourrait-il afficher 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 transféré ma classe d'extracteurs de phrases en 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 périphériques différents et un émulateur sont affichés 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 séries): 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 équipés de processeurs ARM, Java a obtenu de meilleurs résultats 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 machine virtuel Mono et les librairies 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 # fonctionne ici beaucoup plus rapidement. Voici mes résultats:

Émulateur 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 passages): 1543 ms, avec un total de lecture de fichier: 1642 ms

J'ai alors remarqué qu'il y avait une mise à jour de la version bêta de Xamarin.Android, version 4.7.11, avec des notes de mise à jour mentionnant également certains changements dans Mono Runtime. 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: Grand temps total (5 séries): 8103 ms, avec un total de lecture de fichier: 8569 ms

C #: Grand temps total (5 séries): 7951 ms, avec un total de lecture de 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: Grand temps total (5 séries): 9675 ms, avec un total de lecture de fichier: 10028 ms

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

Ici C # semble être seulement un peu 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 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 séries): 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. Avertissement: impossible d'utiliser la classe std :: regex sur Android, donc j'ai dû écrire mes propres routines spécialisées en cherchant des ruptures de paragraphes ou des balises html. Mes tests initiaux du même code sur un PC en utilisant regex, étaient environ 4 à 5 fois plus rapides que Java.

Phew! En réveillant la mémoire brute avec les pointeurs char * ou wchar *, je me suis immédiatement senti 20 ans plus jeune! :)

Modifier 15 juillet 2013

(S'il vous plaît voir ci-dessous, avec des modifications du 30/07/2013, pour de meilleurs résultats avec Dot42)

Avec quelques difficultés, j'ai réussi à porter mes tests C # sur Dot42 (version 1.0.1.71 beta), une autre plate-forme C # pour Android. Les résultats préliminaires montrent que le code Dot42 est environ 3x (3 fois) plus lent que Xamarin C # (v. 4.7.11), sur un émulateur Intel. Un problème est que la classe System.Text.RegularExpressions dans Dot42 n'a pas la fonction Split () que j'ai utilisée dans les tests Xamarin, donc j'ai utilisé la classe Java.Util.Regex à la place, et Java.Util.Regex.Pattern.Split ( ), donc à cet endroit particulier dans le code, il y a cette petite différence. Cela ne devrait pas être un gros problème. Dot42 compile au code Dalvik (DEX), donc il coopère avec Java sur Android nativement, ne nécessite pas d'interopérabilité coûteuse de C # vers Java comme Xamarin.

Juste pour la comparaison, je cours également le test sur les dispositifs ARM - ici le code Dot42 est "seulement" 2x plus lent que Xamarin C #. Voici mes résultats:

HTC Nexus One Android 2.3.7 (ARM)

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

Xamarin C #: Grand temps total (5 séries): 13935 ms, avec un total de lecture de fichier: 14465 ms

Dot42 C #: Grand temps total (5 séries): 26000 ms, avec un total de lecture de fichier: 27168 ms

Samsung Galaxy Note 2, Android 4.1.1 (ARM)

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

Xamarin C #: Grand temps total (5 passages): 6466 ms, avec un total de lecture de fichier: 6720 ms

Dot42 C #: Grand temps total (5 séries): 11185 ms, avec un total de lecture de fichier: 11843 ms

Émulateur Intel, Android 4.2 (x86)

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

Xamarin C #: Grand temps total (5 séries): 1748 ms, avec un total de lecture de fichier: 1933 ms

Dot42 C #: Grand temps total (5 séries): 5150 ms, avec un total de lecture de fichier: 5459 ms

Pour moi, il était également intéressant de noter que Xamarin C # est légèrement plus rapide que Java sur un appareil ARM plus récent, et légèrement plus lent sur l'ancien Nexus One. Si quelqu'un souhaite exécuter ces tests également, faites le moi savoir et je mettrai à jour les sources sur GitHub. Il serait particulièrement intéressant de voir les résultats d'un vrai appareil Android avec processeur Intel.

Mise à jour le 26/07/2013

Juste une mise à jour rapide, re-compilé par les applications de référence avec le dernier Xamarin.Android 4.8, et aussi avec mise à jour dot42 1.0.1.72 publié aujourd'hui - pas de changements significatifs à partir des résultats rapportés avant.

Mise à jour 7/30/2013 - de meilleurs résultats pour dot42

Re-testé Dot42 avec le port de Robert (de dot42 makers) de mon code Java en C #. Dans mon port C # initialement fait pour Xamarin, j'ai remplacé certaines classes Java natives, comme ListArray, avec une classe List native à C #, etc. Robert n'avait pas mon code source Dot42, donc il l'a porté de Java et utilisé des classes Java originales de tels endroits, ce qui profite à Dot42, je suppose que cela fonctionne dans Dalvik VM, comme Java, et pas dans Mono, comme Xamarin. Maintenant, les résultats de Dot42 sont bien meilleurs. Voici un journal de mes tests:

30/07/2013 - Tests Dot42 avec plus de classes Java en Dot42 C #

Émulateur Intel, Android 4.2

Dot42, le code de Greg utilisant StringBuilder.Replace () (comme dans Xamarin):
Grand temps total (5 passages): 3646 ms, avec un total de lecture de fichier: 3830 ms

Dot42, le code de Greg utilisant String.Replace () (comme dans Java et le code de Robert):
Grand temps total (5 séries): 3027 ms, avec un total de lecture de fichier: 3206 ms

Dot42, le code de Robert:
Grand temps total (5 séries): 1781 ms, avec un total de lecture de fichier: 1999 ms

Xamarin:
Grand temps total (5 passages): 1373 ms, avec un total de lecture de fichier: 1505 ms

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

BRAS, Samsung Galaxy Note 2, économie d'énergie, Android 4.1.1

Dot42, le code de Greg utilisant StringBuilder.Replace () (comme dans Xamarin):
Grand temps total (5 séries): 10875 ms, avec un total de lecture de fichier: 11280 ms

Dot42, le code de Greg utilisant String.Replace () (comme dans Java et le code de Robert):
Grand temps total (5 séries): 9710 ms, avec un total de lecture de fichier: 10097 ms

Dot42, le code de Robert:
Grand temps total (5 séries): 6279 ms, avec un total de lecture de fichier: 6622 ms

Xamarin:
Grand temps total (5 séries): 6201 ms, avec un total de lecture de fichier: 6476 ms

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

Je pense toujours que Dot42 a un long chemin à parcourir. Avoir des classes de type Java (par exemple ArrayList) et une bonne performance avec eux, rendrait le portage du code de Java vers C # légèrement plus facile. Cependant, c'est quelque chose que je ne serais pas susceptible de faire beaucoup. Je préférerais utiliser le code C # existant (bibliothèques etc.), qui utilisera des classes C # natives (par exemple List), et qui fonctionnerait lentement avec le code dot42 actuel, et très bien avec Xamarin.

Greg


Oui, la machine virtuelle Mono de Xamarin est plus impressionnante que Dalvik de Google utilisée sous Android. Je l'ai testé avec les tablettes HTC Flyer et Acer Iconia Tab pour comparer le portage C # d'Android à Mono et Java Dalvik, avec l'implémentation C # d'Android qui trébuche bel et bien sur Dalvik basé sur Java.


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 de traitement: Octa-core 1,9 GHz Cortex-A53 Mémoire vive: 3 Go Résolution d'affichage: 1920 × 1080

iPhone 6s : Version iOS: 10.3.3 Unité centrale: Dual-core 1,84 GHz Twister 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

API de repos

Ensemble de tests visant à mesurer le temps nécessaire à l'application pour envoyer une requête via l'API REST et recevoir la réponse sans autre traitement de données, en utilisant l'API OpenWeatherMap.

Opérations JSON Tests réalisés à l'aide du framework Newtonsoft Json.net pour sérialiser et désérialiser les objets JSON dans toutes les applications Xamarin. La sérialisation et la désérialisation Android native ont été 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 :

(Les opérations JSON natives iOS détruisent ce test btw, et Xamarin le rejoint dans la seconde)

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

Quelque chose a semblé incertain au sujet des résultats de Xamarin.Forms pour ce test, ainsi il n'est 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.

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 :)


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 ont dû être réécrits pour la version Android.

Ce que nous avons découvert est que l'E / S dans Xamarin C # est environ 2x plus lente 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.

Il est également révélateur 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.



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

Test arithmétique

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

Travailler avec des chaînes

UPD: nouvelles données avec Google Pixel 2 (merci yousha-aleayoub )


Ceci est un autre blog plus mis à jour que je voudrais partager avec vous . Il compare Xamarin au code natif et Cordova à la fois sur IO et Android.

En un mot, 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é qu'il y a une partie 2







dot42