Vergleich der Speichernutzung verschiedener Toolkit-GUIs


Hallo allerseits! Unser Team entwickelt eine IDE für die Arbeit mit der TestMace- API. In einem unserer vorherigen Artikel wiesen die Leser auf den exorbitant hohen Speicherverbrauch von Elektronenanwendungen hin. Nun, die Zeit der Zahlen ist gekommen :) In diesem Artikel schätzt der Autor den Speicherverbrauch von Einzelfensteranwendungen, die mit verschiedenen Toolkits geschrieben wurden. Viel Spaß beim Lesen!


Als ich die perfekten Tools zum Erstellen einer GUI gefunden hatte, entschied ich mich, den Speicherbedarf zu messen.


Tatsächlich wollte ich herausfinden, welches für ein Programm, das aus einem leeren Fenster besteht, am wenigsten Speicher benötigt. In diesem Artikel werde ich über die Ergebnisse sprechen.



Haftungsausschluss


Dieser Artikel enthält Informationen zum Speicher, den das Programm belegt, wenn verschiedene Tools, Frameworks und Bibliotheken zum Erstellen von GUIs unter Linux verwendet werden. Alle Messungen wurden auf demselben Computer mit Ubuntu 19.04 (Disco Dingo) x86_64 unter Verwendung des Programms Ksysguard durchgeführt, das Daten zum internen Speicher liefert, der von Anwendungen verbraucht wird. Ich habe das System nicht speziell für den Test neu installiert. Es wurde auf meinem allgegenwärtigen Ubuntu durchgeführt, auf dem bereits verschiedene Pakete installiert waren, was die Ergebnisse beeinflussen / verzerren könnte.


Für einige Tools habe ich sogar Messungen hinzugefügt, die unter Windows 10 erhalten wurden und mit Linux kaum zu vergleichen sind, aber es ist interessant zu sehen.


Ich möchte darauf hinweisen, dass meine Messungen keinen wissenschaftlichen Wert haben. Mit anderen Anfangsdaten können Sie völlig andere Ergebnisse erzielen.



Nicht so einfach wie es sich anhört


Was müssen wir also messen? Virtueller Speicher (VSZ)? Resident Memory (RSS)? Eigenes RSS? Geteiltes RSS?


Kurz gesagt, dann ... Ich glaube, dass es beim Vergleich zweier identischer Programme, die mit unterschiedlichen Werkzeugen entwickelt wurden, am genauesten ist, den Prozessumfang des eigenen Speichers mit Smaps zu messen. Ksysguard verwendet Smaps, um detaillierte Speicherinformationen anzuzeigen. In meinem Experiment habe ich jedoch von Anfang an standardmäßig die Daten aus dem RAM-Verbrauchsbereich verwendet, und erst dann wurde mir bewusst, dass Smaps genauere Zahlen liefern. Um die Datenkonsistenz sicherzustellen, habe ich die Informationen aus dem Standard-RAM-Bereich für alle in der Liste aufgeführten Tools verwendet, obwohl bei Verwendung einer Schnittstelle mit einer detaillierten Beschreibung des Speicherverbrauchs höchstwahrscheinlich eine ähnliche Situation zu beobachten war.


Wenn genauer gesagt, dann ... hätte ich in diesem Artikel nicht genug Platz für Lektionen zur Speicherverwaltung unter Linux gehabt, und außerdem gibt es bereits viele wertvolle Materialien zu diesem Thema: ELC: Wie viel Speicher verwenden Anwendungen wirklich? , Das / proc-Dateisystem , proc - Prozessinformations-Pseudodateisystem , Linux-Speicherverwaltungsübersicht , Speicherverwaltung


Liste der Werkzeuge und ihrer Speicherindikatoren


Kein Wort mehr. Hier sind meine Ergebnisse:


GUI-ToolkitEigener Speicher (MB)Bemerkungen
xcb0,132
xlib0,156
nuklear (rawfb)0,624erhöht nicht den von Xorg verbrauchten Speicher
xforms0,765
WINAPI (Win10)1,00unter Windows 10
dlib1.10
SDL2 (ohne opengl)1.10
Gdk1,20
Turbo Vision1.30TUI
Nana1,40
Motiv1,50
Fltk1,70
Msegui2,04
Fox2.20
Nuklear (x11)2.200,4 MB + 1,8 MB Xorg-Speicher
WINAPI (WEIN)2.30
LCL (kundenspezifisch gezeichnet)2,50
Gtk + 22,80
wxX113.00nicht betriebsbereit in der Produktion
libui4.00
LCL (GTK)4.50
Gtk + 35.00
wxGtk36.00
Efl7.20
GLFW9.00
JUCE10.00Projucer binär, das Fenster ist nicht leer
Sciter10.00ca. 10 MB, Linux Scapp fehlt
LCUI11.00 Uhr
GLUI12.50
SFML13.20
Nanogui14.00 Uhr
Sdl14.00 Uhr
U ++14.00 Uhr
Agar15:00 Uhr
Sehr geehrte ImGUI (SDL)15.30 Uhr
Guilite15.80
Sehr geehrte ImGUI (SDL / Vulkan)16.50
Mono WinForms16.564unter Windows 10
Qt17 Uhr
Ultraleicht20.00 Uhr
Träumerei23.50
Java Swing59,30OpenJDK 12
Elektron74,60
Javafx80,00OpenJDK 12
horus_ui94,00
Flattern Desktop98.00upd: in den frühen Entwicklungsstadien!
Boost.UI- -verwendet wxWidgets
CEGUI- -Wie sammle ich es? :(?
IUP- -Verwendet ähnlich wie wxWdigets gtk + unter Linux
Lgi- -verwendet gtk + 2
Minigui- -Montage fehlgeschlagen
Morda- -Montage fehlgeschlagen
SFGUI- -verwendet SFML
TGUI- -verwendet SFML
Grünspan- -verwendet qt


Ich war überrascht von der Völlerei von Flutter, da es ursprünglich als Framework für die Erstellung einer GUI für mobile Geräte konzipiert wurde.

UPD (mein Dank geht an kirbyfan64sos ): Flutter Desktop befindet sich noch in einem frühen Entwicklungsstadium und alle Builds debuggen. Dies bedeutet, dass alle Profiler (wie Observatory) aktiv sind, alle Debug-Anweisungen aktiviert sind und der AoT-Compiler deaktiviert ist. Es wird interessant sein, die Daten mithilfe des Release-Builds zu überprüfen.


Ich werde nicht sagen, dass mich die Leistung von Electron beeindruckt hat.


Mit HorusUI hatte ich eine ungefähre Größe von 20 MB erwartet, da OpenGL und der Sofort-Rendering-Modus der GUI verwendet werden. Ich verstehe nicht, warum die Figur mehr herauskam.


Swing- und JavaFX-Java-Frameworks haben ebenfalls interessante Ergebnisse gezeigt. Beide sind äußerst unersättlich. Wenn Sie sich nicht sicher sind, welches für Ihr neues Java-Projekt geeignet ist, sollten Sie sich für das bequemere und modernere JavaFX-Framework entscheiden, obwohl Sie es mit etwas mehr Speicher füllen müssen. Aber wenn Ihr Gedächtnis Gold wert ist, wählen Sie natürlich Swing.


Qt zeigte auch sehr interessante Zahlen und erwies sich als viel unersättlicher als die meisten anderen populären Werkzeuge. Es ist erwähnenswert, dass der größte Teil des von ihm belegten Speichers die Menge ist, die der auf meinem System installierte amdgpu-Treiber verbraucht. Möglicherweise liegt dies daran, dass OpenGL-Puffer lokal gespeichert werden. Dasselbe gilt für SDL2: Ein Programm ohne OpenGL verbraucht 1,1 MB und damit bis zu 14 MB.


WxWidgets und LCL sind in diesem Vergleich gut platziert. Trotz der Tatsache, dass sie Wrapper über andere Tools für die GUI sind, sind die Kosten für Ressourcen minimal. Ich bin beeindruckt von der Idee, das Backend beispielsweise von Gtk + auf Qt zu übertragen und so die Unabhängigkeit von Tools zu gewährleisten.


Ich werde auch Nuklear hervorheben, einfach weil es meiner Meinung nach einen sehr coolen GUI-Sofort-Rendering-Modus hat. Wenn Sie durch die Verwendung des rohen X11-Framebuffers nicht verwirrt sind, belegt Ihre Einzelfensteranwendung nur 0,624 MB, was sehr beeindruckend aussieht.


Fazit


Wenn Sie gehofft haben, hier allgemeine Schlussfolgerungen zu ziehen, muss ich Sie leider enttäuschen.

Source: https://habr.com/ru/post/de464327/


All Articles