webentwicklung-frage-antwort-db.com.de

Hat jemand Benchmarks (Code & Ergebnisse), um die Leistung von Android Apps, die in Xamarin C # und Java geschrieben wurden) zu vergleichen?

Ich bin auf Xamarin gestoßen, der behauptet, dass ihre Mono-Implementierung auf Android und ihre mit C # kompilierten Apps schneller sind als Java Code. Hat jemand tatsächliche Benchmarks für sehr ähnlichen Java und C # -Code auf verschiedenen Android Plattformen durchgeführt, um solche Behauptungen zu überprüfen, und konnte den Code und die Ergebnisse veröffentlichen?

Hinzugefügt am 18. Juni 2013

Da es keine Antwort gab und solche Benchmarks von anderen nicht gefunden werden konnten, entschied ich mich, meine eigenen Tests durchzuführen. Leider bleibt meine Frage "gesperrt", so dass ich dies nicht als Antwort posten kann, sondern nur die Frage bearbeite. Bitte stimmen Sie ab, um diese Frage erneut zu öffnen. Für C # habe ich Xamarin.Android Ver. 4.7.09001 (beta). Der Quellcode, alle Daten, die ich zum Testen und Kompilieren von APK-Paketen verwendet habe, sind auf GitHub:

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

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

Wenn jemand meine Tests auf anderen Geräten oder Emulatoren wiederholen möchte, wäre ich interessiert, auch die Ergebnisse zu erfahren.

Ergebnisse meiner Tests

Ich habe meine Satzextraktionsklasse nach C # portiert (aus meiner @ Voice Aloud Reader-App) und einige Tests mit 10 HTML-Dateien in Englisch, Russisch, Französisch, Polnisch und Tschechisch durchgeführt. Jeder Lauf wurde fünfmal mit allen zehn Dateien durchgeführt. Die Gesamtzeit für drei verschiedene Geräte und einen Emulator ist unten angegeben. Ich habe nur "Release" Builds getestet, ohne dass das Debuggen aktiviert ist.

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

Java: Gesamtsumme der Zeit (5 Läufe): 12361 ms, mit einer Gesamtsumme der gelesenen Dateien: 13304 ms

C #: Gesamtsumme der Zeit (5 Durchläufe): 17504 ms, mit einer Gesamtsumme der gelesenen Dateien: 17956 ms

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

Java: Gesamtsumme der Zeit (5 Läufe): 8947 ms, mit einer Gesamtsumme der gelesenen Dateien: 9186 ms

C #: Gesamtsumme der Zeit (5 Durchläufe): 9884 ms, mit einer Gesamtsumme der gelesenen Dateien: 10247 ms

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

Java: Gesamtsumme Zeit (5 Läufe): 9742 ms, mit Dateilesung insgesamt: 10111 ms

C #: Gesamtsumme der Zeit (5 Durchläufe): 10459 ms, wobei die Datei insgesamt 10696 ms liest

Emulator - Intel (Android 4.2, API 17)

Java: Gesamtsumme (5 Läufe): 2699 ms, mit einer Gesamtsumme von 3127 ms

C #: Gesamtsumme der Zeit (5 Durchläufe): 2049 ms, mit einer Gesamtsumme der gelesenen Dateien: 2182 ms

Emulator - Intel (Android 2.3.7, API 10)

Java: Gesamtsumme Zeit (5 Läufe): 2992 ms, mit Dateilesung insgesamt: 3591 ms

C #: Gesamtsumme Zeit (5 Läufe): 2049 ms, mit Dateilesesumme: 2257 ms

Emulator - Arm (Android 4.0.4, API 15)

Java: Gesamtsumme der Zeit (5 Läufe): 41751 ms, mit einer Gesamtsumme der gelesenen Dateien: 43866 ms

C #: Gesamtsumme (5 Durchläufe): 44136 ms, mit einer Gesamtsumme zum Lesen der Datei: 45109 ms

Kurze Diskussion

Mein Testcode enthält hauptsächlich das Parsen, Ersetzen und Regex-Suchen von Text. Vielleicht sind die Ergebnisse für anderen Code (z. B. mehr numerische Operationen) anders. Auf allen Geräten mit ARM Prozessoren schnitt Java besser ab als Xamarin C # -Code. Der größte Unterschied bestand unter Android 2.3, bei dem C # -Code mit ca. 70% der Geschwindigkeit von Java.

Auf dem Intel-Emulator (mit Intel HAX-Technologie wird der Emulator im schnellen virtuellen Modus ausgeführt) führt Xamarin C # -Code meinen Beispielcode viel schneller aus als Java - ungefähr 1,35-mal schneller. Vielleicht sind der Code und die Bibliotheken der virtuellen Mono-Maschine unter Intel viel besser optimiert als unter ARM?

8. Juli 2013 bearbeiten

Ich habe gerade den Genymotion Android-Emulator installiert, der in Oracle VirtualBox ausgeführt wird, und auch hier wird ein nativer Intel-Prozessor verwendet, der nicht den ARM-Prozessor emuliert. Wie beim Intel HAX Emulator läuft auch hier C # viel schneller. Hier sind meine Ergebnisse:

Genymotion-Emulator - Intel (Android 4.1.1, API 16)

Java: Gesamtsumme der Zeit (5 Läufe): 2069 ms, mit einer Gesamtsumme der gelesenen Dateien: 2248 ms

C #: Gesamtsumme der Zeit (5 Durchläufe): 1543 ms, mit einer Gesamtsumme der gelesenen Dateien: 1642 ms

Ich bemerkte dann, dass es ein Update für Xamarin.Android Beta, Version 4.7.11 gab, mit Versionshinweisen, die auch einige Änderungen in der Mono-Laufzeit erwähnen. Beschlossen, einige ARM Geräte schnell zu testen, und große Überraschung - C # -Nummern verbessert:

BN Nook XD +, ARM (Android 4.0)

Java: Gesamtsumme der Zeit (5 Läufe): 8103 ms, mit einer Gesamtsumme der gelesenen Dateien: 8569 ms

C #: Gesamtsumme der Zeit (5 Durchläufe): 7951 ms, mit einer Gesamtsumme der gelesenen Dateien: 8161 ms

Beeindruckend! C # ist jetzt besser als Java? Beschlossen, den Test auf meinem Galaxy Note 2 zu wiederholen:

Samsung Galaxy Note 2 - ARM (Android 4.1.1)

Java: Gesamtsumme (5 Läufe): 9675 ms, mit einer Gesamtsumme von 10028 ms für das Lesen von Dateien

C #: Gesamtsumme der Zeit (5 Läufe): 9911 ms, mit einer Gesamtsumme der gelesenen Dateien: 10104 ms

Hier scheint C # nur etwas langsamer zu sein, aber diese Zahlen gaben mir eine Pause: Warum ist die Zeit länger als bei Nook HD +, obwohl Note 2 einen schnelleren Prozessor hat? Die Antwort: Energiesparmodus. In Nook war es deaktiviert, in Note 2 - aktiviert. Beschlossen, mit deaktiviertem Energiesparmodus zu testen (wie bei aktiviert, begrenzt es auch die Prozessorgeschwindigkeit):

Samsung Galaxy Note 2 - ARM (Android 4.1.1), Energiesparmodus deaktiviert

Java: Gesamtsumme (5 Läufe): 7153 ms, mit einer Gesamtsumme von 7459 ms

C #: Gesamtsumme der Zeit (5 Läufe): 6906 ms, mit einer Gesamtsumme der gelesenen Dateien: 7070 ms

Jetzt ist C # überraschenderweise auch etwas schneller als Java auf ARM Prozessor. Großer Fortschritt!

Bearbeiten 12. Juli 2013

Wir alle wissen, dass nichts schneller ist als nativer Code, und ich war mit der Leistung meines Satzteilers in Java oder C # nicht zufrieden, insbesondere, dass ich ihn verbessern (und damit noch langsamer machen) muss. . Beschlossen, es in C++ neu zu schreiben. Im Folgenden sehen Sie einen kleinen Vergleich (d. H. Eine kleinere Anzahl von Dateien als bei früheren Tests aus anderen Gründen) der Geschwindigkeit von nativem und von Java auf meinem Galaxy Note 2 mit deaktiviertem Energiesparmodus:

Java: Gesamtsumme der Zeit (5 Läufe): 3292 ms, mit einer Gesamtsumme der gelesenen Dateien: 3454 ms

Native Thumb: Gesamtsumme der Zeit (5 Läufe): 537 ms, mit einer Gesamtsumme der gelesenen Dateien: 657 ms

Eingeborener Arm: Gesamtsumme der Zeit (5 Läufe): 458 ms, mit einer Gesamtsumme der gelesenen Dateien: 587 ms

Für meinen speziellen Test ist der native Code sechs- bis siebenmal schneller als Java. Vorsichtsmaßnahme: Konnte die Klasse std :: regex unter Android nicht verwenden und musste daher meine eigenen speziellen Routinen schreiben, um nach Absätzen und HTML-Tags zu suchen. Meine ersten Tests desselben Codes auf einem PC mit Regex waren ungefähr vier- bis fünfmal schneller als mit Java.

Puh! Ich habe mich sofort 20 Jahre jünger gefühlt, als ich das rohe Gedächtnis wieder mit char * oder wchar * Zeigern weckte! :)

Edit 15. Juli 2013

(Siehe unten, mit Änderungen vom 30.07.2013, für viel bessere Ergebnisse mit Dot42)

Mit einigen Schwierigkeiten konnte ich meine C # -Tests auf Dot42 (Version 1.0.1.71 Beta) portieren, eine andere C # -Plattform für Android. Vorläufige Ergebnisse zeigen, dass Dot42-Code auf einem Intel Android-Emulator etwa dreimal (dreimal) langsamer ist als Xamarin C # (Version 4.7.11). Ein Problem ist, dass die System.Text.RegularExpressions-Klasse in Dot42 nicht über die Funktion Split () verfügt, die ich in Xamarin-Tests verwendet habe. Daher habe ich stattdessen die Java.Util.Regex-Klasse und Java.Util.Regex.Pattern.Split () verwendet. An dieser Stelle im Code gibt es also diesen kleinen Unterschied. Sollte aber kein großes Problem sein. Dot42 wird in Dalvik (DEX) -Code kompiliert, arbeitet also mit Java auf Android zusammen und benötigt keine teure Interoperabilität von C # zu Java wie Xamarin.

Zum Vergleich führe ich den Test auch auf ARM Geräten durch - hier ist der Dot42-Code "nur" 2x langsamer als Xamarin C #. Hier sind meine Ergebnisse:

HTC Nexus One Android 2.3.7 (ARM)

Java: Gesamtsumme Zeit (5 Läufe): 12187 ms, mit Dateilesesumme: 13200 ms

Xamarin C #: Gesamtsumme Zeit (5 Läufe): 13935 ms, mit Dateilesesumme: 14465 ms

Dot42 C #: Gesamtsumme der Zeit (5 Durchläufe): 26000 ms, mit einer Gesamtsumme der gelesenen Dateien: 27168 ms

Samsung Galaxy Note 2, Android 4.1.1 (ARM)

Java: Gesamtsumme der Zeit (5 Läufe): 6895 ms, mit einer Gesamtsumme der gelesenen Dateien: 7275 ms

Xamarin C #: Gesamtsumme der Zeit (5 Läufe): 6466 ms, mit einer Gesamtsumme der gelesenen Dateien: 6720 ms

Dot42 C #: Gesamtsumme der Zeit (5 Durchläufe): 11185 ms, mit einer Gesamtsumme der gelesenen Dateien: 11843 ms

Intel Emulator, Android 4.2 (x86)

Java: Gesamtsumme der Zeit (5 Läufe): 2389 ms, mit einer Gesamtsumme der gelesenen Dateien: 2770 ms

Xamarin C #: Gesamtsumme der Zeit (5 Läufe): 1748 ms, mit einer Gesamtsumme der gelesenen Dateien: 1933 ms

Dot42 C #: Gesamtsumme (5 Läufe): 5150 ms, mit einer Gesamtsumme zum Lesen der Datei: 5459 ms

Für mich war es auch interessant festzustellen, dass Xamarin C # auf einem neueren Java Gerät etwas schneller als ARM und auf dem alten Nexus One etwas langsamer ist. Wenn jemand diese Tests auch durchführen möchte, lass es mich wissen und ich aktualisiere die Quellen auf GitHub. Es wäre besonders interessant, Ergebnisse von einem realen Android Gerät mit Intel-Prozessor zu sehen.

Update 26.07.2013

Nur ein kurzes Update, das von Benchmark-Apps mit dem neuesten Xamarin.Android 4.8 und dem heute veröffentlichten dot42 1.0.1.72-Update neu kompiliert wurde - keine wesentlichen Änderungen gegenüber den zuvor gemeldeten Ergebnissen.

Update 30.07.2013 - bessere Ergebnisse für dot42

Erneutes Testen von Dot42 mit Roberts (von dot42 makers) Portierung meines Java Codes auf C #. In meinem C # -Port, der ursprünglich für Xamarin erstellt wurde, habe ich einige native Java -Klassen wie ListArray durch eine native List-Klasse für C # usw. ersetzt. Robert hatte meinen Dot42-Quellcode nicht, also portierte er ihn erneut von Java und hat an solchen Stellen die ursprünglichen Klassen Java verwendet. Dies kommt Dot42 zugute, da es in Dalvik VM wie Java und nicht in Mono wie Xamarin ausgeführt wird. Jetzt sind die Dot42-Ergebnisse viel besser. Hier ist ein Protokoll von meinen Tests:

30.07.2013 - Dot42 testet mit mehr Java Klassen in Dot42 C #

Intel Emulator, Android 4.2

Dot42, Gregs Code mit StringBuilder.Replace () (wie in Xamarin):
Gesamtsumme Zeit (5 Läufe): 3646 ms, mit Dateilesesumme: 3830 ms

Dot42, Gregs Code mit String.Replace () (wie in Java und Roberts Code):
Gesamtsumme Zeit (5 Läufe): 3027 ms, mit Dateilesesumme: 3206 ms

Dot42, Roberts Code:
Gesamtsumme Zeit (5 Läufe): 1781 ms, mit Dateilesesumme: 1999 ms

Xamarin:
Gesamtsumme Zeit (5 Läufe): 1373 ms, mit Dateilesesumme: 1505 ms

Java:
Gesamtsumme Zeit (5 Läufe): 1841 ms, mit Dateilesesumme: 2044 ms

ARM, Samsung Galaxy Note 2, Energiesparmodus deaktiviert, Android 4.1.1

Dot42, Gregs Code mit StringBuilder.Replace () (wie in Xamarin):
Gesamtsumme Zeit (5 Läufe): 10875 ms, mit Dateilesesumme: 11280 ms

Dot42, Gregs Code mit String.Replace () (wie in Java und Roberts Code):
Gesamtsumme Zeit (5 Läufe): 9710 ms, mit Dateilesesumme: 10097 ms

Dot42, Roberts Code:
Gesamtsumme Zeit (5 Läufe): 6279 ms, mit Dateilesesumme: 6622 ms

Xamarin:
Gesamtsumme Zeit (5 Läufe): 6201 ms, mit Dateilesesumme: 6476 ms

Java:
Gesamtsumme Zeit (5 Läufe): 7141 ms, mit Dateilesesumme: 7479 ms

Ich denke immer noch, dass Dot42 einen langen Weg vor sich hat. Wenn Java-ähnliche Klassen (z. B. ArrayList) und eine gute Leistung mit diesen Klassen vorhanden sind, wird das Portieren von Code von Java nach C # etwas einfacher. Dies ist jedoch etwas, was ich wahrscheinlich nicht viel tun würde. Ich würde lieber vorhandenen C # -Code (Bibliotheken usw.) verwenden, der native C # -Klassen (z. B. List) verwendet, und das würde mit dem aktuellen dot42-Code langsam und mit Xamarin sehr gut funktionieren.

Greg

530
gregko

Ja, die virtuelle Mono-Maschine von Xamarin ist beeindruckender als die in Android verwendete Dalvik von Google. Ich habe es mit HTC Flyer- und Acer Iconia Tab-Tablets getestet, um den C # -Port von Android durch Mono mit Java Dalvik zu vergleichen, und zwar mit der C # -Implementierung von Android und wirklich den Java-basierten Dalvik unter Druck zu setzen.

62
klvtsov
I came across this interesting post

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

Android App Performance

iOS App Performance

Hoffe, diese Informationen helfen.

Dies ist ein weiterer aktualisierter Blog-Beitrag, den ich mit Ihnen teilen möchte . Er vergleicht Xamarin mit nativem Code und Cordova auf IOs und Android.

Kurz gesagt, Xamarin bietet manchmal eine bessere Leistung als nativer Code. Er testete die App-Größe, die Ladezeiten, das Laden einer Liste aus dem Azure-Dienst und die Primzahlberechnung.

Genießen!

Bearbeiten: Ich habe den toten Link aktualisiert und festgestellt, dass es gibt einen Teil 2

34
Daniel

Hier sind einige Informationen, die ich in einem anderen Test zwischen native, Xamarin und Xamarin.Forms-Lösungen (die Tests umfassen auch iOS-Leistungen) auf den beiden folgenden Geräten gefunden habe:

Samsung Galaxy A7 : Android Betriebssystemversion: 6.0 Zentraleinheit: Octa-Core-Cortex-A53-Arbeitsspeicher mit 1,9 GHz : 3 GB Bildschirmauflösung: 1920 × 1080

iPhone 6s : iOS-Version: 10.3.3 Zentraleinheit: Dual-Core 1,84 GHz Twister-RAM: 2 GB Bildschirmauflösung: 1334 × 750

Es werden einige gemeinsame Funktionen verglichen, von denen jede ihre eigene Anwendung hat:

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

Jeder Test wird mehrmals wiederholt, die Grafiken zeigen die durchschnittlichen Ergebnisse.


Hallo Welt

Basic Hellow World performance comparison


Rest API

Eine Reihe von Tests zur Messung der Zeit, die die App benötigt, um eine Anforderung über die REST API zu senden und die Antwort ohne weitere Datenverarbeitung mithilfe der OpenWeatherMap-API zurückzuerhalten.

Rest API performance comparison


JSON-Operationen Mit dem Newtonsoft Json.net-Framework durchgeführte Tests zum Serialisieren und Deserialisieren von JSON-Objekten in allen Xamarin-Apps. Native Android Serialisierung und Deserialisierung getestet mit zwei Java Bibliotheken: Jackson und GSON.

Es werden zwei Läufe durchgeführt, einer von Grund auf neu und einer mit zwischengespeicherten Informationen und Operationen

Erster Lauf :

JSON serialization first run

JSON deserialization first run

(Native iOS JSON Operations beendet diesen Test übrigens und Xamarin schließt sich ihm in der zweiten an.)

JSON Serialization second run

JSON Deserialization second run


Fotooperationen

Erstes Laden von Bildern mit drei verschiedenen Auflösungen:

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

Image First Load Android

Image First Load iOS

Etwas schien in Bezug auf die Xamarin.Forms-Ergebnisse für diesen Test unsicher zu sein, daher ist es nicht in der Grafik enthalten.


SQLite-Operationen

Zwei Operationen getestet:

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

Mit Datenbanken mit 10.000 Datensätzen. Alle Vorgänge wurden intern auf Geräten verarbeitet.

SQLite Android performances

SQLite iOS performances


Xamarin Native (Xamarin.iOS/Xamarin.Android) bieten sich als gute Alternativen zum nativen Code an, während Xamarin.Forms in vielen Fällen langsam erscheint, aber es kann eine sehr gute Lösung sein, um sehr einfache Anwendungen schnell zu entwickeln.

Ein vollständiger Test stammt aus dieser Quelle:

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

Vielen Dank, dass Sie mir die Erklärungen zur Verbesserung meiner Antwort gegeben haben. Ich hoffe, dies hilft ein wenig :)

10
Burgito

Performance

Performance ist ein vages Wort, wenn Sie nicht definieren, was Sie unter Performance verstehen, wenn es sich um reine Rechenleistung handelt. Xamarin kann je nach Art der Berechnung schneller als Java) sein.

Android wird standardmäßig mit Multipe-Formularen geliefert, mit denen Code ausgeführt werden kann in:

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

Es ist ziemlich offensichtlich, dass die Ausführung von Code umso schneller vonstatten geht, je nativer die Lösung ist. Eine laufzeitbasierte Sprache schlägt niemals eine Sprache, die direkt auf der CPU ausgeführt wird.

Aber auf der anderen Seite, wenn Sie die tatsächliche Nutzungsleistung messen möchten Java ist propbaby schneller als Xamarin.

Xamarin und warum kann es langsamer sein

Beim Vergleich von Xamarin mit normalen alten Java) - Anwendungen kann die Leistung von Xamarin sehr wohl schneller sein, da sie langsamer sein kann.

In einem realen Beispiel sind Xamarin-Anwendungen sehr wahrscheinlich langsamer als Java=) Anwendungen, da viele Android/Java (System) -Aufrufe zur und von der Xamarin-Laufzeit mithilfe sogenannter Bindungen delegiert werden müssen .

Es gibt verschiedene Arten von Bindungen, die Sie unbedingt kennen sollten:

  • JNI (Java Native Interface): Die Bindung, die in vielen Android) - Anwendungen für die Schnittstelle zwischen Java Code (SDK) und nativer C++ - Code (NDK).
  • MCW (Managed Callable Wrapper): Eine Bindung, die in Xamarin für die Schnittstelle von verwaltetem C # -Code zu Java Code verfügbar ist (Android-Laufzeit).
  • ACW (Android Callable Wrappers): Eine Bindung, die in Xamarin für die Schnittstelle von Java code (Android run- Zeit) zu verwaltetem C # -Code.

Weitere Informationen zu MCW und ACW finden Sie hier: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/

Bindungen sind in Bezug auf die Leistung sehr sehr kostenintensiv. Das Aufrufen einer C++ - Methode aus Java fügt einen enormen Zeitaufwand beim Aufrufen hinzu. Das Aufrufen einer C++ - Methode aus C++ heraus ist um ein Vielfaches schneller.

Jemand hat einen Leistungstest durchgeführt, um zu berechnen, wie viele Java Operationen im Durchschnitt einen JNI-Anruf kosten: Was ist der quantitative Aufwand für einen JNI-Anruf?

Aber nicht nur JNI-Anrufe sind teuer, sondern auch Anrufe von und nach MCW und ACW. Xamarin-Anwendungen in der realen Welt führen viele Aufrufe mit Bindungen durch. Aufgrund dieser realen Welt kann die Verwendung einer Xamarin-Anwendung langsamer sein (und wird dies im Allgemeinen auch sein) als eine einfache alte Java) - Anwendung. Jedoch abhängig davon, wie Für die Xamarin-Anwendung ist es sehr wahrscheinlich, dass der Benutzer den Unterschied nicht einmal bemerkt.

TLDR/Fazit: Xamarin muss alle Bindungen verwenden, die zeitaufwendig sind.

Neben den Bindungen gibt es viele andere Faktoren, die für die tatsächliche Leistung von Bedeutung sind, z. B. die Größe der Binärdatei, das Laden der App im Speicher, E/A-Vorgänge und vieles mehr. Ein Blog-Beitrag, der einige dieser Dinge untersucht, ist hier zu finden: https://magenic.com/thinking/mobile-development-platform-performance-part-2-native-cordova-classic-xamarin-xamarin- Formen

7
Rolf ツ

Es sind ziemlich alte Tests, aber sie könnten relevant sein: https://github.com/EgorBo/Xamarin.Android-vs-Java

Rechenprüfung

enter image description here

Sammlungen, Generika, benutzerdefinierte Werttypen

enter image description here

Mit Strings arbeiten

enter image description here

UPD: neue Daten mit Google Pixel 2 (danke yousha-aleayoub )

Pixel 2 tests

2
Denis Gordin