Bonjour à tous! Notre équipe développe un IDE pour travailler avec l'API TestMace . Dans l'un de nos articles précédents, les lecteurs ont souligné la consommation de mémoire prohibitive des applications d'électrons. Eh bien, l'heure des chiffres est venue :) Dans cet article, l'auteur estime la consommation de mémoire des applications à fenêtre unique écrites à l'aide de différentes boîtes à outils. Bonne lecture!
Trouver l'ensemble parfait d'outils pour créer une interface graphique, j'ai décidé de mesurer la quantité de mémoire qu'ils occupaient.
En fait, je voulais savoir laquelle nécessitait le moins de mémoire pour un programme composé d'une fenêtre vide. Dans cet article, je parlerai des résultats.
Clause de non-responsabilité
Cet article fournit des informations sur la mémoire occupée par le programme lors de l'utilisation de divers outils, frameworks et bibliothèques pour créer des interfaces graphiques sous Linux. Toutes les mesures ont été effectuées sur le même ordinateur avec Ubuntu 19.04 (Disco Dingo) x86_64 à l'aide du programme Ksysguard, qui fournit des données sur la mémoire interne consommée par les applications. Je n'ai pas réinstallé le système spécifiquement pour le test. Il a été effectué sur mon Ubuntu omniprésent, sur lequel divers packages étaient déjà installés, ce qui pourrait affecter / déformer les résultats.
Pour certains outils, j'ai même ajouté des mesures obtenues sur Windows 10, qui peuvent difficilement être comparées à Linux, mais c'est intéressant à voir.
Je tiens à noter que mes mesures n'ont pas de valeur scientifique. En ayant d'autres données initiales, vous pouvez obtenir des résultats complètement différents.
Pas aussi simple qu'il y paraît
Alors, que devons-nous mesurer? Mémoire virtuelle (VSZ)? Mémoire résidente (RSS)? Propre RSS? RSS partagé?
En bref, alors ... je crois qu'en comparant deux programmes identiques développés à l'aide de différents ensembles d'outils, il sera plus précis de mesurer la quantité de processus de sa propre mémoire avec des smaps. Ksysguard utilise des smaps pour afficher des informations détaillées sur la mémoire. Cependant, dès le début, dans mon expérience, j'ai utilisé les données du panneau de consommation de RAM par défaut, et c'est seulement alors que j'ai pris conscience que les smaps donnaient des chiffres plus précis. Afin d'assurer la cohérence des données, j'ai utilisé les informations du panneau RAM par défaut pour tous les outils présentés dans la liste, bien que très probablement, en utilisant une interface avec une description détaillée de la consommation de mémoire, une situation similaire pourrait être observée.
Si plus en détail, alors ... dans cet article, je n'aurais pas eu assez de place pour des leçons sur la gestion de la mémoire sous Linux, et en plus, il y a déjà beaucoup de documents utiles sur ce sujet: ELC: Combien de mémoire les applications utilisent-elles vraiment? , Le système de fichiers / proc , proc - pseudo-système d'informations sur les processus , Présentation de la gestion de la mémoire Linux , Gestion de la mémoire
Liste des outils et de leurs indicateurs de mémoire
Pas un mot de plus. Voici mes résultats:
J'ai été surpris par la gourmandise de Flutter, étant donné qu'il a été initialement conçu comme un cadre pour créer une interface graphique pour les appareils mobiles.UPD (mes remerciements à kirbyfan64sos ): Flutter Desktop en est encore aux premiers stades de développement, et toutes les versions sont en train de déboguer. Cela signifie que tous les profileurs (comme Observatoire) sont actifs, toutes les instructions de débogage sont activées et le compilateur AoT est désactivé. Il sera intéressant de revérifier les données à l'aide de la version Release.
Je ne dirai pas que j'ai été frappé par la performance d'Electron.
Avec HorusUI, je m'attendais à un chiffre approximatif de 20 Mo, car il utilise OpenGL et le mode de rendu immédiat de l'interface graphique. Je ne comprends pas pourquoi le chiffre est sorti plus.
Les frameworks Java Swing et JavaFX ont également montré des résultats intéressants. Les deux sont extrêmement insatiables, et si vous n'êtes pas sûr de celui qui conviendrait à votre nouveau projet Java, il semble raisonnable d'opter pour le cadre JavaFX plus pratique et moderne, bien que vous deviez le remplir avec un peu plus de mémoire. Mais si votre mémoire vaut son pesant d'or, alors, bien sûr, choisissez Swing.
Qt a également montré des chiffres très intéressants et s'est avéré beaucoup plus vorace que la plupart des autres outils populaires. Il convient de noter que la majeure partie de la mémoire occupée est la quantité consommée par le pilote amdgpu installé sur mon système. C'est peut-être parce que les tampons OpenGL sont stockés localement. La même chose peut être observée avec SDL2: un programme sans OpenGL consomme 1,1 Mo, et avec lui jusqu'à 14 Mo.
WxWidgets et LCL sont bien placés dans cette comparaison. Malgré le fait qu'ils sont des wrappers sur d'autres outils pour l'interface graphique, le coût des ressources est minime. Je suis impressionné par l'idée de la possibilité de transférer le backend de Gtk +, par exemple, vers Qt, garantissant ainsi l'indépendance des outils.
Je vais également mettre en évidence Nuklear, simplement parce que, il me semble, il a un mode de rendu immédiat très sympa. Si vous n'êtes pas dérouté par l'utilisation du framebuffer X11 brut, votre application à fenêtre unique n'occupera que 0,624 Mo, ce qui semble très impressionnant.
Conclusion
Si vous espériez voir des conclusions générales ici, alors, je le crains, je dois vous décevoir.