Est-ce que quelqu'un a des benchmarks (code & résultats) comparant les performances des applications Android écrites en Xamarin C# et Java? [fermé]
Je suis tombé sur Xamarin affirme que leur mono implémentation sur Android et leurs applications compilées C# sont plus rapides que le code Java. Est-ce que quelqu'un a effectué des benchmarks réels sur Java et c# code très similaires sur différentes plates-formes Android pour vérifier de telles allégations, pourrait afficher le code et les résultats?
Ajouté Le 18 Juin 2013
étant donné qu'il n'y avait pas de réponse et que je n'ai pas pu trouver de telles références faites par d'autres, j'ai décidé de faire mes propres tests. Malheureusement, mon question reste "locked" donc je ne peux pas poster cela comme la réponse, seulement éditer la question. S'il vous plaît voter pour ouvrir à nouveau cette question. Pour C#, J'ai utilisé de la Xamarine.Android Ver. 4.7.09001 (bêta). Le code source, toutes les données que j'ai utilisées pour tester et compiler les paquets APK sont sur GitHub:
Java: https://github.com/gregko/TtsSetup_Java
c#: https://github.com/gregko/TtsSetup_C_sharp
si quelqu'un voudrais réitérer mes tests sur d'autres appareils ou des émulateurs, je serais intéressé de connaitre les résultats.
résultats de mes tests
j'ai porté ma classe d'extracteur de phrases à C# (à partir de l'application My @Voice Aloud Reader) et j'ai effectué quelques 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 sont affichés ci-dessous. Je testé "Libération" s'appuie uniquement, sans le débogage activé.
HTC Nexus One Android 2.3.7 (API 10) - CyanogenMod ROM
Java: Grand temps total (5 pistes): 12361 ms, avec la lecture des fichiers total: 13304 ms
C#: Grand temps total (5 pistes): 17504 ms, avec la lecture des fichiers total: 17956 ms
Samsung Galaxy S2 SGH-I777 (Android 4.0.4, API 15) - CyanogenMod ROM
Java: Grand temps total (5 exécution): 8947 ms, avec lecture de fichier total: 9186 ms
C#: Grand temps total (5 pistes): 9884 ms, avec la lecture des fichiers total: 10247 ms
Samsung GT-N7100 (Android 4.1.1 JellyBean, API 16) - Samsung ROM
Java: Grand temps total (5 pistes): 9742 ms, avec la lecture des fichiers total: 10111 ms
C#: Grand temps total (5 pistes): 10459 ms, avec la lecture des fichiers total: 10696 ms
Émulateur-Intel (Android 4.2, API 17)
Java: Grand temps total (5 pistes): 2699 ms, avec la lecture des fichiers total: 3127 ms
C#: Grand temps total (5 pistes): 2049 ms, avec la lecture des fichiers total: 2182 ms
émulateur-Intel (Android 2.3.7, API 10)
Java: Grand temps total (5 pistes): 2992 ms, avec la lecture des fichiers total: 3591 ms
C#: Grand temps total (5 pistes): 2049 ms, avec la lecture des fichiers total: 2257 ms
de l'Émulateur - Bras (Android 4.0.4, l'API 15)
Java: Grand temps total (5 pistes): 41751 ms, avec la lecture des fichiers total: 43866 ms
C#: Grand temps total (5 pistes): 44136 ms, avec la lecture des fichiers total: 45109 ms
brève discussion
mon code 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érent. Sur tous les appareils équipés de processeurs ARM, Java a donné de meilleurs résultats que le code Xamarin c#. La plus grande différence a été sous Android 2.3, où C # code fonctionne à environ. 70% de la vitesse Java.
sur l'émulateur Intel (avec la technologie Intel HAX, l'émulateur fonctionne en mode FAST virt), Xamarin C# code exécute mon code d'échantillon beaucoup plus rapidement que Java - environ 1,35 fois plus vite. Peut-être que les bibliothèques et le code machine mono virtuel sont mieux optimisés sur Intel que sur ARM?
Modifier Le 8 Juillet 2013
je viens d'installer L'émulateur Android de Genymotion, qui tourne dans Oracle VirtualBox, et encore une fois celui-ci utilise un processeur Intel natif, pas un processeur emulating ARM. Comme avec L'émulateur Intel HAX, c # tourne ici beaucoup plus vite. Voici mes résultats:
émulateur Genymotion-Intel (Android 4.1.1, API 16)
Java: Total général temps (5 passages): 2069 ms, avec lecture du fichier total: 2248 ms
C#: Grand temps total (5 pistes): 1543 ms, avec la lecture des fichiers total: 1642 ms
j'ai alors remarqué qu'il y avait une mise à jour de Xamarin.Beta Android, version 4.7.11, avec des notes de mentionner certains changements dans le Mono exécution. Décidé de tester rapidement certains dispositifs de bras, et grande surprise-C# nombres amélioré:
BN Nook XD+, ARM (Android 4.0)
Java: Grand temps total (5 passages)): 8103 ms, avec lecture de fichier total: 8569 ms
C#: Grand temps total (5 pistes): 7951 ms, avec la lecture des fichiers total: 8161 ms
Wow! C# est maintenant mieux que Java? Décidé de répéter le test sur ma Galaxy Note 2:
Samsung Galaxy Note 2-ARM (Android 4.1.1)
Java: Grand temps total (5 pistes): 9675 ms, avec la lecture des fichiers total: 10028 ms
C#: Grand temps total (5 pistes): 9911 ms, avec la lecture des fichiers total: 10104 ms
ici C# semble être seulement légèrement plus lent, mais ces nombres m'ont donné 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: Mode d'économie d'énergie. Sur Nook, il était désactivé, sur la Note 2 - activé. Décidé de tester avec le mode d'économie d'énergie désactivé (activé, il limite également la vitesse de processeur):
Samsung Galaxy Note 2-bras (Android 4.1.1), économie d'énergie désactivé
Java: Grand temps total (5 pistes): 7153 ms, avec la lecture des fichiers total: 7459 ms
C#: Grand temps total (5 pistes): 6906 ms, avec la lecture des fichiers total: 7070 ms
maintenant, étonnamment, C# est légèrement plus rapide que Java sur le processeur ARM ainsi. Grande amélioration!
Edit 12 Juillet 2013
nous savons tous, que rien ne bat le code natif pour la vitesse, et je n'étais pas satisfait de la performance de ma phrase splitter en Java ou C#, en particulier que je dois l'améliorer (et donc le rendre encore plus lent). Décidé de le ré-écrire en C++. Voici une petite (c.-à-d. un ensemble plus petit de fichiers que les tests précédents, pour d'autres raisons) comparaison de la vitesse de Java par rapport à natif sur ma Galaxy Note 2, avec le mode d'économie d'énergie désactivé:
Java: Temps total (5 passages): 3292 ms, avec lecture de fichier total: 3454 ms
pouce indigène: Grand temps total (5 pistes): 537 ms, avec la lecture des fichiers total: 657 ms
arm Natif: Grand temps total (5 pistes): 458 ms, avec la lecture des fichiers total: 587 ms
ressemble à pour mon test particulier, le code natif est 6 à 7 fois plus rapide que Java. Avertissement: ne pouvait pas utiliser la classe STD:: regex sur Android, donc a dû écrire mes propres routines spécialisées à la recherche de paragraphes breaks ou balises html. Mes premiers tests du même code sur un PC utilisant regex, étaient environ 4 à 5 fois plus rapides que Java.
Phew! Se réveiller la mémoire brute avec des pointeurs char* ou wchar* encore une fois, je me suis immédiatement senti 20 ans plus jeune! :)
Edit 15 Juillet 2013
(Veuillez voir ci-dessous, avec les modifications de 7/30/2013, pour de bien meilleurs résultats avec Dot42)
avec quelques difficultés, j'ai réussi à porter mon C# tests to Dot42 (version 1.0.1.71 beta), une autre plate-forme C# Pour Android. Les résultats préliminaires montrent que Dot42 code est environ 3x (3 fois) plus lent que Xamarin c# (v. 4.7.11), sur un émulateur Intel Android. Un problème est ce système.Texte.La classe RegularExpressions dans Dot42 n'a pas la fonction Split() que j'ai utilisée dans les tests Xamarin, donc J'ai utilisé Java.Util.Classe Regex à la place, et Java.Util.Regex.Modèle.Split(), donc dans ce lieu particulier dans le code, il y a cette petite différence. Ne doit pas être un gros problème. Dot42 compiles to Dalvik (DEX) code, de sorte qu'il coopère avec Java sur Android nativement, n'a pas besoin interop coûteux de C# à Java comme Xamarin.
juste à titre de comparaison, je fais aussi le test sur des appareils 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: temps total (5 passages): 12187 ms, avec lecture de fichier total: 13200 ms
Xamarin C#: Grand temps total (5 pistes): 13935 ms, avec la lecture des fichiers total: 14465 ms
Dot42 C#: Grand temps total (5 pistes): 26000 ms, avec la lecture des fichiers total: 27168 ms
Samsung Galaxy Note 2, Android 4.1.1 (ARM)
Java: Grand temps total (5 pistes): 6895 ms, avec la lecture des fichiers total: 7275 ms
Xamarin C#: Grand le temps total (5 pistes): 6466 ms, avec la lecture des fichiers total: 6720 ms
Dot42 C#: Grand temps total (5 pistes): 11185 ms, avec la lecture des fichiers total: 11843 ms
émulateur Intel, Android 4.2 (x86)
Java: Grand temps total (5 pistes): 2389 ms, avec la lecture des fichiers total: 2770 ms
Xamarin C#: Grand temps total (5 pistes): 1748 ms, avec la lecture des fichiers total: 1933 ms
Dot42 C#: Grand temps total (5 pistes): 5150 ms, avec la lecture des fichiers total: 5459 ms
pour moi, il était également intéressant de noter que Xamarin c# est légèrement plus rapide que Java sur un nouvel appareil ARM et légèrement plus lent sur L'ancien Nexus One. Si quelqu'un veut faire ces tests aussi, s'il vous plaît, 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 véritable appareil Android avec processeur Intel.
mise à jour 26/07/2013
juste une mise à jour rapide, ré-compilé par benchmark apps avec la dernière Xamarin.Android 4.8, et aussi avec dot42 1.0.1.72 mise à jour publiée aujourd'hui - aucun changement significatif par rapport aux résultats rapportés avant.
mise à jour 30/07/2013 - de meilleurs résultats pour dot42
a testé Dot42 avec le port de Robert (de dot42 makers) de mon code Java vers C#. Dans mon C # port fait initialement pour Xamarin, Je remplacé quelques classes Java natives,comme ListArray, par une classe List native à C#, etc. Robert n'avait pas mon code source Dot42, donc il l'a porté à nouveau depuis Java et a utilisé des classes Java originales dans ces endroits, ce qui profite à Dot42, je suppose parce qu'il fonctionne en Dalvik VM, comme Java, et pas en Mono, comme Xamarin. Maintenant Dot42 résultats sont beaucoup mieux. Voici un journal de mes tests:
7/30/2013 - tests Dot42 avec plus de classes Java dans Dot42 c#
émulateur Intel, Android 4.2
Dot42, le Code de Greg utilisant StringBuilder.Remplacer () (comme dans Xamarin):
Grand temps total (5 pistes): 3646 ms, avec la lecture des fichiers total: 3830 msDot42, le Code de Greg utilisant une chaîne.Remplacer () (comme dans Java et Robert's code):
Grand temps total (5 pistes): 3027 ms, avec la lecture des fichiers total: 3206 msDot42, Robert's Code:
Grand temps total (5 pistes): 1781 ms, avec la lecture des fichiers total: 1999 msXamarin:
Temps total général (5 passages): 1373 ms, avec lecture du fichier total: 1505 msJava:
Grand temps total (5 pistes): 1841 ms, avec la lecture des fichiers total: 2044 msle BRAS, le Samsung Galaxy Note 2, économie d'énergie hors tension, Android 4.1.1
Dot42, le Code de Greg utilisant StringBuilder.Remplacer () (comme dans Xamarin):
Grand temps total (5 pistes): 10875 ms, avec la lecture des fichiers total: 11280 msDot42, le Code de Greg utilisant une chaîne.Remplacer () (comme dans Java et Robert's code):
Grand temps total (5 pistes): 9710 ms, avec la lecture des fichiers total: 10097 msDot42, Robert'S Code:
Grand temps total (5 total: 6622 msXamarin:
Total général temps (5 passages): 6201 ms, avec lecture du fichier total: 6476 msJava:
Temps total général (5 passages): 7 141 ms, avec lecture du fichier total: 7 479 ms
je pense toujours que Dot42 a encore un long chemin à parcourir. Avoir des classes Java-like (par exemple ArrayList) et une bonne performance avec eux serait rendre le transfert de code de Java en C# légèrement plus facile. Toutefois, il est peu probable que je le fasse beaucoup. Je préférerais utiliser le code C# existant (bibliothèques, etc.).), qui utilisera les classes natives C# (e.g. List), et qui fonctionnerait lentement avec le code dot42 actuel, et très bien avec Xamarin.
Greg
7 réponses
Oui, la machine virtuelle Mono de Xamarin est plus impressionnante que la Dalvik de Google utilisée sur Android. Je l'ai testé avec HTC Flyer et Acer Iconia Tab comprimés pour comparer le C# port D'Android à travers Mono contre Java Dalvik, avec la mise en œuvre C# D'Android bien et vraiment trouncing la base Java Dalvik.
I came across this interesting post
https://medium.com/@harrycheung/mobile-app-performance-redux-e512be94f976#.kfbauchtz
espérons que cette information aide.
C'est un autre billet de blog plus récent que je voudrais partager avec vous . Il compare Xamarin au code natif et Cordova sur iOS et Android.
en bref, Xamarin donne parfois de meilleurs résultats que le code natif. Il a testé la taille de l'application, les temps de charge, le chargement d'une liste de service Azure et le calcul du nombre premier.
Profitez-en!
Edit: j'ai mis à jour le lien mort et j'ai remarqué que il y a une partie 2
nous avons récemment étudié L'utilisation de la Xamarine 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, c'est que l'E/S dans Xamarin c# est environ 2 fois plus lent que Java. Notre application est fortement dépendant des e/S. Nous n'en avons pas encore découvert la cause, mais pour le moment, nous présumons qu'elle est due à la formation de coalitions. Pendant que nous essayons de rester à l'intérieur la plupart du temps, nous ne savons pas comment Mono accède au disque.
c'est aussi dire que notre code C utilise SQLite.NET ( https://github.com/praeclarum/sqlite-net ). Les SQLite.NET code sont également 2X plus lent que L'utilisation de Java SQLite wrapper 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 tellement plus lent. Une possibilité est que la formation des cordes de natif à Java peut être plus rapide sur Android que natif à C# est sur Xamarin.
voici quelques informations que j'ai trouvées dans un autre test entre natif, Xamarin et Xamarin.Forms solutions (les tests comprennent également les performances iOS) sur les deux dispositifs suivants:
Samsung Galaxy A7 : Version Android OS: 6.0 Unité centrale de traitement: 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-core 1,84 GHz RAM: 2 GB Résolution d'affichage: 1334×750
la Comparaison est faite sur quelques caractéristiques communes, chacune avec sa propre demande :
- Basic “Hello World”
- REST API
- JSON Serialization/Deserialization
- Photo Loading
- SQL Database Insert and Get All
chaque test est repété plusieurs fois, les graphiques montrent les résultats moyens.
Bonjour Tout Le Monde
Rest API
ensemble de tests visant à mesurer le temps qu'il faut à l'application pour envoyer une demande par le biais de L'API REST et recevoir la réponse sans autre traitement de données, en utilisant L'API Openweatermap.
JSON Operations Les Tests effectués utilisation de Newtonsoft Json.net cadre pour sérialiser et désérialiser les objets JSON dans toutes les applications Xamarin. La sérialisation et la desérialisation natives Android ont été testées en utilisant deux bibliothèques Java: Jackson et GSON.
deux passages sont réalisés, un premier à partir de zéro et un second avec des infos et des opérations en cache
Première manche :
(Native iOS JSON Opérations est en train de tuer ce test btw, et Xamarin la rejoint dans la seconde)
Opérations Photographiques
première charge sur des 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 semblait incertain au sujet de la Xamarine.Les formulaires de résultats pour ce test, il n'est pas inclus dans le graphique.
SQLite Operations
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 des appareils.
Xamarin Native (Xamarin.iOS / Xamarin.Android) se montrent comme de bonnes alternatives au code natif, alors que Xamarin.Les formes semble lent, dans beaucoup de cas, mais il peut être une très bonne solution pour développer des applications très simples rapidement.
Test Complet vient de cette source:
Merci de me donner les explications pour améliorer ma réponse, j'espère que ça vous aide un peu :)
Performance
Performance est un mot vague si vous ne définissez pas ce que vous voulez dire par performance, Si C'est simple performance de calcul Xamarin peut être plus rapide que Java selon la nature du calcul.
Android nativly vient avec des formulaires multipe pour exécuter le code dans:
- RenderScript (CPU and GPU)
- Java (SDK)
- C++ (NDK)
- OpenGL (GPU)
il est tout à fait évident que plus la solution est native, plus elle sera rapide lors de l'exécution du code. Un langage basé sur le temps d'exécution ne battra jamais un langage qui tourne directement sur le CPU.
mais d'un autre côté si vous voulez mesurer la performance d'utilisation réelle Java est propbaby va être plus rapide que Xamarin.
Xamarin et pourquoi il peut être plus lent
en comparant Xamarin avec de vieilles applications Java simples, les performances peuvent très bien être plus rapides pour Xamarin car elles peuvent être plus lentes.
dans un monde réel exemple les applications Xamarin sont très susceptibles d'être plus lentes que les applications Java parce que de nombreux appels Android/Java (système) doivent être délégués à et à partir de L'exécution Xamarin en utilisant ce qu'on appelle des fixations.
il y a quelques types différents de reliures 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 (Managed Callable Wrappers): une reliure qui est disponible en Xamarin pour l'interface du code C géré au code Java (Android run-time).
- ACW (Android Callable Wrappers): une liaison qui est disponible en Xamarin à l'interface de Java code (Android run-time) en code C géré.
Les fixationspour en savoir plus sur MCW et ACW, Cliquez ici: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform /
sont très coûteuses en termes de performances. Le fait D'invoquer une méthode C++ de Java ajoute un énorme overhead dans le temps d'appel, appelant un La méthode C++ de L'intérieur de C++ est beaucoup beaucoup de fois plus rapide.
Quelqu'un a fait un test de performance pour calculer combien D'opérations Java en moyenne un coût d'appel JNI: Quels sont les frais généraux quantitatifs de faire un appel JNI?
mais non seulement les appels JNI sont coûteux ainsi que les appels à destination et en provenance de MCW et ACW. Applications Xamarin monde réel font de nombreux appels en utilisant des fixations et à cause de cette utilisation du monde réel d'une application Xamarin peut être (et sera en général) plus lent qu'une simple ancienne application Java. Cependant, selon la façon dont L'application Xamarin a été conçue, il est très probable que l'utilisateur ne remarquera même pas la différence.
TLDR/Conclusion: Xamarin a besoin d'utiliser toutes les fixations, qui sont coûteuses en temps.
outre les reliures, il y a beaucoup d'autres facteurs impliqués quand on parle de monde réel performances, par exemple: Taille du binaire, chargement de l'application en mémoire, opérations d'e/s et bien plus encore. Un billet de blog qui étudie certaines de ces choses peut être trouvé ici: https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin-forms
ce sont des tests assez anciens mais qui pourraient être pertinents: https://github.com/EgorBo/Xamarin.Android-vs-Java
essai 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 )
