Comparison of memory usage of different toolkit GUI
Hello! Our team is developing an IDE to work with the TestMace API. In one of our previous articles, readers pointed to the exorbitantly high memory consumption of electron applications. Well, the time of numbers has come :) In this article, the author estimates the memory consumption of single-window applications written using various toolkits. Enjoy reading!
Finding the perfect set of tools for creating a GUI, I decided to measure the amount of memory they occupied.
In fact, I wanted to find out which one requires the least amount of memory for a program consisting of one empty window. In this article I will talk about the results.
Disclaimer
This article provides information about the memory occupied by the program when using various tools, frameworks and libraries for creating GUIs on Linux. All measurements were made on the same computer with Ubuntu 19.04 (Disco Dingo) x86_64 using the Ksysguard program, which provides data on the internal memory consumed by applications. I did not reinstall the system specifically for the test. It was executed on my ubiquitous Ubuntu, on which various packages were already installed, which could affect / distort the results.
For some tools, I even added measurements obtained on Windows 10, which can hardly be compared with Linux, but it's interesting to see.
I want to note that my measurements are not of scientific value. Having other initial data, you can get completely different results.
Not as easy as it sounds
So what do we need to measure? Virtual memory (VSZ)? Resident memory (RSS)? Own RSS? Shared RSS?
In short, then ... I believe that when comparing two identical programs developed using different sets of tools, it will be most accurate to measure the amount of internal memory occupied by the process with smaps. Ksysguard uses smaps to display detailed memory information. However, from the very beginning, in my experiment, I used the data from the RAM consumption panel by default, and only then I became aware that smaps give more accurate numbers. In order to ensure data consistency, I used the information from the default RAM panel for all the tools presented in the list, although most likely, using an interface with a detailed description of memory consumption, a similar situation could be seen.
If in more detail, then ... in this article I would not have enough space for lessons on memory management in Linux, and besides, there are already many worthy materials on this topic: ELC: How much memory are applications really using? , The / proc Filesystem , proc - process information pseudo-filesystem , Linux Memory Management Overview , Memory Management
List of tools and their memory indicators
Not a word more. Here are my results:
| GUI toolkit | Own memory (MB) | Remarks |
| xcb | 0.132 | |
| xlib | 0.156 | |
| nuklear (rawfb) | 0.624 | does not increase the memory consumed by Xorg |
| xforms | 0.765 | |
| WINAPI (Win10) | 1.00 | on windows 10 |
| dlib | 1.10 | |
| SDL2 (without opengl) | 1.10 | |
| Gdk | 1.20 | |
| turbo vision | 1.30 | TUI |
| nana | 1.40 | |
| Motif | 1.50 | |
| Fltk | 1.70 | |
| Msegui | 2.04 | |
| Fox | 2.20 | |
| nuklear (x11) | 2.20 | 0.4 MB + 1.8 MB Xorg memory |
| WINAPI (WINE) | 2.30 | |
| LCL (customdrawn) | 2.50 | |
| Gtk + 2 | 2.80 | |
| wxX11 | 3.00 | not ready for use in production |
| libui | 4.00 | |
| LCL (GTK) | 4.50 | |
| Gtk + 3 | 5.00 | |
| wxGtk3 | 6.00 | |
| Efl | 7.20 | |
| GLFW | 9.00 | |
| JUCE | 10.00 | Projucer binary, the window is not empty |
| Sciter | 10.00 | about 10 MB, missing Linux Scapp |
| LCUI | 11.00 | |
| GLUI | 12.50 | |
| SFML | 13.20 | |
| nanogui | 2 p.m. | |
| Sdl | 2 p.m. | |
| U ++ | 2 p.m. | |
| Agar | 3 p.m. | |
| Dear ImGUI (SDL) | 15.30 | |
| Guilite | 15.80 | |
| Dear ImGUI (SDL / Vulkan) | 16.50 | |
| Mono WinForms | 16.564 | on windows 10 |
| Qt | 5 p.m. | |
| Ultralight | 20.00 | |
| revery | 23.50 | |
| Java swing | 59.30 | OpenJDK 12 |
| electron | 74.60 | |
| Javafx | 80.00 | OpenJDK 12 |
| horus_ui | 94.00 | |
| Flutter desktop | 98.00 | upd: in the early stages of development! |
| Boost.UI | - | uses wxWidgets |
| CEGUI | - | How to collect it? :(? |
| IUP | - | similar to wxWdigets, uses gtk + on Linux |
| Lgi | - | uses gtk + 2 |
| Minigui | - | assembly failed |
| morda | - | assembly failed |
| SFGUI | - | uses SFML |
| TGUI | - | uses SFML |
| Verdigris | - | uses qt |
UPD (my thanks to kirbyfan64sos ): Flutter Desktop is still in the early stages of development, and all builds are debugging. This means that all profilers (like Observatory) are active, all debug statements are enabled, and the AoT compiler is disabled. It will be interesting to double-check the data using the release build.
I will not say that I was struck by the performance of Electron.
With HorusUI, I was expecting an approximate figure of 20 MB, because it uses OpenGL and the immediate rendering mode of the GUI. I don’t understand why the figure came out more.
Swing and JavaFX Java frameworks have also shown interesting results. Both of them are extremely insatiable, and if you are not sure which one would be suitable for your new Java project, then it seems reasonable to opt for the more convenient and modern JavaFX framework, although you will have to fill it with a little more memory. But if your memory is worth its weight in gold, then, of course, choose Swing.
Qt also showed very interesting figures and was much more voracious than most other popular tools. It is worth noting that most of the memory occupied by it is the amount consumed by the amdgpu driver installed on my system. Maybe this is because OpenGL buffers are stored locally. The same can be seen with SDL2: a program without OpenGL consumes 1.1 MB, and with it as much as 14 MB.
WxWidgets and LCL are well placed in this comparison. Despite the fact that they are wrappers over other tools for the GUI, the cost of resources is minimal. I am impressed with the idea of the possibility of transferring the backend from Gtk +, for example, to Qt, thereby guaranteeing independence from tools.
I’ll also highlight Nuklear, simply because, it seems to me, it has a very cool mode for instant GUI rendering. If you are not confused by the use of the raw X11 framebuffer, your single-window application will occupy only 0.624 MB, which looks very impressive.
Conclusion
If you were hoping to see any generalized conclusions here, then, I am afraid, I have to disappoint you.
All Articles