A GTK 4 application showing an empty window uses about 160 MB of RAM:
$ wget https://movq.de/v/138ab3e622/win.c
$ cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)
$ ./win
It also takes several seconds to start on my machine because it is compiling shaders and initializing DRI (it’s faster on the second run, unless you happen to lose ~/.cache/mesa_shader_cache/). This might be a hint as to why it’s using so much memory: There’s obviously much more going on behind the scenes these days, not just a little bit of internal housekeeping and then creating a window.
@movq@www.uninformativ.de That memory usage rivals Electron, which runs an instance of Chromium for each program. What do you need shaders for, and why can’t you turn them off?
~160MB of memory just to show an empty window?! And some think a few (single digit) MB of memory is bad for Go web apps that serve “Hello World” 😅
Have we really gotten that lazy and inefficient? 🤔
@movq@www.uninformativ.de
Doesn’t even compile on my system, which is apparently broken:
> cc -Wall -Wextra -o win win.c $(pkg-config --cflags --libs gtk4)
cc: error: unrecognized argument in option ‘-mfpmath=sse -msse -msse2 -pthread -I/usr/include/gtk-4.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/graphene-1.0 -I/usr/lib/x86_64-linux-gnu/graphene-1.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0’
cc: note: valid arguments to ‘-mfpmath=’ are: 387 387+sse 387,sse both sse sse+387 sse,387
@movq@www.uninformativ.de If I understand it correctly, gtk4 renders using OpenGL. That means some of that RAM that appears to be allocated is actually some trick of the OpenGL driver so that it can map address in RAM space to the GPU’s VRAM (depends a lot on your setup though).
What happens if you run it with GSK_RENDERER=cairo set?
@abucci@anthony.buc.ci Yes, that appears to be the case. I stumbled upon GSK_RENDERER=cairo a while ago – it helps with the startup times and a little bit with memory consumption, which is down to about 130 MB.
Still quite heavy and startup times are noticeably longer than GTK 3. It’s not that much, but it’s there.
In my case, I wanted to port xiate from GTK 3 to GTK 4. But that much memory usage for just one terminal window (of which there are usually many, so we’re talking about gigabytes here) is too much. GTK might have its use cases, but I think it’s no longer the right toolkit for me.
I don’t want to hate on it too much. I know too little of the internal details of all this, so I don’t have an informed opinion.
(Before anyone suggests it: Yes, I could have one process show many terminal windows. That would be a lot faster and would use a lot less memory. But I explicitly do not want that. xiate used to have this model – until one day at work, a bug in the terminal library VTE crashed all my terminal windows at once. It really only crashed one window, but since they all ran in the same process, they were all gone. This is unacceptable.)
Have we really gotten that lazy and inefficient? 🤔
That’s the question. It certainly strikes me as odd that everything keeps getting bigger, heavier, slower all the time. But why is that? I refuse to believe that this is just incompetence. 😅