Mesurer les performances Qt

J'ai décidé de continuer la série d'articles sur le système d'exploitation Aurora (jusqu'à récemment appelé Sailfish). Pendant le temps que je travaille avec ce système d'exploitation, j'ai accumulé diverses observations qui se rapportent aux performances des applications sur Qt et le système dans son ensemble, car il est suspendu avec une variété d'appareils, comme un arbre de Noël, je remarque toutes les petites choses au démarrage. Je pense que cela peut être intéressant et utile pour les collègues qui travaillent également avec Qt (ou travailleront bientôt). Suggérez que vous puissiez tester plus.



Je programme en Qt et discute souvent avec des collègues, des développeurs iOS, des similitudes, des différences et des avantages des approches. À un moment donné, nous avons encore décidé de passer des mots aux actes et de prendre des mesures. Nous n'avons pas trouvé de programmeur Android prêt à participer à notre divertissement, donc une comparaison avec la participation des nombres et des tables ne sera que pour Swift et C ++.

Je tiens à vous rappeler que Qt / C ++ n'impose pas son mécanisme de gestion de la mémoire, et l'utilisateur lui-même résout ce problème dans le cadre des capacités disponibles en C ++, tandis que dans le comptage de référence Swift est utilisé, et en Java, c'est un garbage collector. Ainsi, le programmeur a la possibilité d'interagir plus efficacement avec la mémoire. Afin d'envoyer une demande http ou de lire des données à partir d'une base de données, Qt s'appuie sur ses propres forces et n'utilise pas de cadres prêts à l'emploi fournis par le système d'exploitation. Exceptions - interagir avec le clavier, dessiner la fenêtre de démarrage de l'application, afficher des notifications et d'autres choses.

Test 1

Tout d'abord, nous avons décidé d'écrire un algorithme simple (le tamis d'Eratosthène), de l'exécuter sur de grands nombres et de comparer le temps de calcul. Lancé sur iPhone 7.

Programme Swift:

swift // // ViewController.swift // Eratosthenes // // Created by Dmitry Shadrin on 22/11/2018. // Copyright 2018 Digital Design. All rights reserved. // import UIKit class ViewController: UIViewController { @IBOutlet weak var digitTextField: UITextField! @IBOutlet weak var timeLabel: UILabel! @IBAction func startAction(_ sender: UIButton) { guard let text = digitTextField.text, let number = Int(text) else { return } prime(n: number) } func prime(n: Int) { let startTime = DispatchTime.now() let _ = PrimeSequence(upTo: n) .reduce(into: [], { $0.append($1) }) //      let endTime = DispatchTime.now() let time = (endTime.uptimeNanoseconds - startTime.uptimeNanoseconds) timeLabel.text = "\(time)" } } public struct PrimeSequence: Sequence { private let iterator: AnyIterator<Int> public init(upTo limit: Int) { self.iterator = AnyIterator(EratosthenesIterator(upTo: limit)) } public func makeIterator() -> AnyIterator<Int> { return iterator } } private struct EratosthenesIterator: IteratorProtocol { let n: Int var composite: [Bool] var current = 2 init(upTo n: Int) { self.n = n self.composite = [Bool](repeating: false, count: n + 1) } mutating func next() -> Int? { while current <= self.n { if !composite[current] { let prime = current for multiple in stride(from: current * current, through: self.n, by: current) { composite[multiple] = true } current += 1 return prime } current += 1 } return nil } } 

Je ne m'attarderai pas sur le code en détail, l'ératosthène linéaire n'est pas évident à comprendre, surtout si l'une des langues ne vous est pas familière. Voici un lien avec une description: https://e-maxx.ru/algo/prime_sieve_linear , qui sont intéressés, peuvent vérifier l'honnêteté. Soit dit en passant, la version rapide s'est avérée être un peu plus optimisée dans les petites choses (vous pouvez les chercher), ce qui n'a pas empêché la version plus de gagner les performances.

Programme Qt:

 #include "eratosthenes.h" #include <stdio.h> #include <stdlib.h> #include <time.h> #include <QVector> #include <QDebug> #include <vector> #include <cmath> Eratosthenes::Eratosthenes(QObject *parent) { time = 0; } void Eratosthenes::qtFunction(int n) { clock_t start, end; start = clock(); std::vector<int> lp = std::vector<int>(n + 1, 0); std::vector<int> pr; //       pr.reserve(std::sqrt(n) / 2); for (int i = 2; i <= n; ++i) { if (lp[i] == 0) { lp[i] = i; pr.emplace_back(i); } for (int j = 0; j < pr.size() && pr[j] <= lp[i] && i * pr[j] <= n; ++j) { lp[i * pr[j]] = pr[j]; } } end = clock(); time = (end - start) / (double)CLOCKS_PER_SEC; pTimeChanged(); qDebug() << "  " << pr.size() << "" << time; } 

Exécutez le programme. Les applications ont un champ pour entrer le nombre n, un bouton de démarrage et un champ avec un temps total:


Swift - à gauche, Qt - à droite.

Résultat. Je vais donner un tableau de mesures pour différents n et à différents moments:

Comme vous pouvez le voir, une application C ++ est environ 1,5 fois plus rapide qu'une application native avec des algorithmes identiques.

Test 2

Naturellement, l'informatique dans le cadre des applications mobiles est une chose importante, mais loin d'être la seule. Par conséquent, nous avons dessiné un ListView composé de 1000 éléments, chacun contenant du texte et une image, afin de regarder la vitesse de rendu des éléments graphiques. Ci-dessous, dans les vidéos, vous pouvez voir le résultat:

Qt:

Rapide:


Visuellement, la différence n'est pas perceptible.

Test 3

Dans l'OS Sailfish, nous avons un noyau Linux et un shell natif graphique sur Qt, et cela en soi suggère des réflexions sur les bonnes performances de cet OS. Je remarque souvent que l'Inoi R7 gagne en termes de vitesse de certaines tâches, bien que le Samsung Galaxy S8 fasse de même. Ainsi, par exemple, le Samsung Galaxy S8 envoie, reçoit, traite, emballe dans une base de données, etc. 10K requêtes HTTP en environ 3-4 minutes, et Inoi R7 fait la même chose pendant 5-6 minutes. Compte tenu de la différence de performance du fer, le résultat est impressionnant.

Pour un test plus honnête des performances du système d'exploitation, j'ai décidé de regarder la vitesse de réponse de la brouette.

Test.cpp:

 #include "mypainter.h" #include <QPainter> MyPainter::MyPainter(QQuickItem *parent) : QQuickPaintedItem(parent) { } void MyPainter::paint(QPainter *painter) { QPen pen; pen.setWidth(10); pen.setColor(Qt::red); painter->setPen(pen); painter->drawPolyline(pol); } void MyPainter::xyCanged(int x, int y) { pol.append(QPoint(x, y)); update(); } 

Test.qml:

 import QtQuick 2.9 import QtQuick.Window 2.2 import Painter 1.0 Window { visible: true Painter { id: painter anchors.fill: parent MouseArea { anchors.fill: parent onPressed: { painter.xyCanged(mouseX, mouseY) } onMouseXChanged: { painter.xyCanged(mouseX, mouseY) } onMouseYChanged: { painter.xyCanged(mouseX, mouseY) } } } } 

Simple et sans prétention. Je n'ai pas de téléphone qui prend en charge Sailfish et Android pour un usage personnel, j'ai donc dû chercher chez mes collègues un téléphone aussi proche que possible d'Inoi r7, mais sur Android. Ce qui s'est avéré soudainement très difficile, étant donné que je suis assis dans un bureau de développement mobile.

Sony Xperia Z5 compact:
Processeur - Qualcomm Snapdragon 810 MSM8994, 2000 MHz
Le nombre de cœurs de processeur - 8
Processeur vidéo - Adreno 430
La quantité de mémoire interne - 32 Go
La quantité de RAM - 2 Go

Inoi R7:
Processeur - Qualcomm Snapdragon 212 MSM8909AA, 1200 MHz
Le nombre de cœurs de processeur - 4
Processeur vidéo - Adreno 304
La quantité de mémoire interne - 16 Go
La quantité de RAM - 2 Go

Sony s'est toujours avéré être plus puissant, mais pour l'équation des cotes, nous activons le mode d'économie d'énergie sur celui-ci, tout de même cela ne conduira pas à l'égalité complète de la puissance des appareils. Sur la vidéo, vous pouvez voir que sur Android, la ligne n'est pas aussi fluide que sur Sailfish.

Gauche - Sony, droite - Inoi:



Je ne dis pas, ce n'est pas un indicateur très sérieux, vous devez comparer non seulement les capacités d'un langage pur, mais aussi différentes bibliothèques, natives et multiplateformes, pour comparer leurs performances et leur facilité d'utilisation, car il y a très peu d'applications qui n'utilisent que ListView et le tamis Eratosthenes. Bien que toutes ces petites choses ensemble me semblent très convaincantes.

Inconvénients

Bien sûr, tout n'est pas si rose avec Qt, comme j'essaye de peindre ici, il y a des inconvénients. Par exemple, en travaillant avec TextInput sur Android, vous pouvez torturer les perfectionnistes qui sont particulièrement sensibles aux béquilles, car sur chaque appareil Qt parvient à mettre des bâtons absolument uniques dans les roues lors de l'interaction avec le clavier. Sur un téléphone, l'image monte, sur l'autre elle reste immobile, mais EnterKey ne fonctionne pas, sur le troisième, seules les majuscules sont toujours saisies, et il n'y a aucun moyen de le convaincre de passer en minuscules. Vous pouvez continuer à l'infini. Et tout cela ralentit aussi! (Les grognements ne sont pertinents que pour Android, il n'y a pas de tels problèmes sur Sailfish, tout fonctionne bien). De plus, sur Qt, il est difficile d'obtenir l'apparence native de l'application.

Conclusion

La principale conclusion qui peut être tirée: Qt, étant un outil multiplateforme, n'est pas inférieur en termes de performances aux outils de développement natifs. Il est parfait pour les programmes dans lesquels, en plus de l'interface graphique, il y a encore beaucoup de mathématiques, et surtout pour les applications d'entreprise, où il y a beaucoup de nuances et peu d'employés, afin de ne pas créer de version indépendante pour chaque OS. Les fonctions sont plus importantes pour les utilisateurs d'entreprise que l'interface utilisateur native. Pour Aurora, Qt est un outil natif pour le développement d'applications, qui donne probablement un autre coup de fouet aux performances.

Il serait intéressant de tester l'Aurora sur un matériel puissant comme mon Galaxy S8.