Comment by magackame
18 hours ago
I think you guys on HN can be a bit out of touch maybe? On my linux machine (measured with tux-manager):
nautilus 177 MB
kitty 150 MB
alacritty 107 MB
mpv --idle --force-window 160 MB
winit empty window + OpenGL context 100 MB
tux-manager 69 MB
hexchat 55 MB
gnome-terminal 47 MB
st 12 MB
xterm 12 MB
All these apps are what you would consider native, good apps. Written with Qt, GTK, some in low level langs like C\C++, Rust as well. There is of course different ways to measure the usage and maybe some more testing needs to be done, but stuff like 1-10 MB seems completely unrealistic. I think any empty Qt/GTK app eats 40 MB at least. Only thing that even gets close is st at 12 MB. And mind you it's a terminal (which is 1000x simpler than any modern GUI app, doesn't load any assets etc) and it doesn't even use any GPU accel (which itself seem to add a lot of baseline cost).
Honestly I was a bit surprised myself. I have a Rust winit + ash vulkan hardcoded triangle demo app and it eats 86 MB (the binary itself is 5.5 MB). I would love to know, if anyone could explain why GPU accel seems to eat up so much RAM. Like yeah, there are a bunch of images that live on swapchain, but they should all be in VRAM. Outside of that I don't see what would require MBs worth of overhead.
Yes these are all very, very complex applications though.
But I agree: using more memory is good, actually, because it means more stuff is being cached. Nautilus is probably pre-indexing directory structure so it doesn't have to read disk every single time you open your home folder. That's good. Oh, and thumbnails. Thumbnails are incredibly expensive memory wise, but very useful!
Also modern apps have A LOT built-in. Tons of font management stuff, accessibility, they work on many different environments. I mean, look at everything that goes into a modern terminal emulator.
But... a weather app is much simpler, IMO, than Nautilus or Kitty.
Counterpoint: Nautilus is both slower and less stable than Windows Explorer on large folders, even though the Linux filesystem is much faster. These super-indexed desktop linux search functions are also dog slow, while `grep` and `find` in the terminal are much faster (for searching inside files), and those certainly don't cache anything.
Windows Explorer crashes for me about ~3 times a day at work, and takes down the taskbar with it, so not sure about more stable. I don't use Nautilus though because it's pretty bare bones compared to Dolphin. Also:
> These super-indexed desktop linux search functions are also dog slow
Baloo-indexed KRunner on Plasma is instant. I index my entire home folder, including hidden files, and I can substring search with imperceptible latency. I can't speak to other search implementations, but yes KRunner + Baloo is much faster than grep.
3 replies →
Thunar is very fast compared to Nautilus.
> Nautilus is probably pre-indexing directory structure so it doesn't have to read disk every single time you open your home folder. That's good
No it isn't good, and no it probably doesn't because it is kernel's job. I'd rather they don't do double caching, and it's actually worse if they do.
Syscalls are expensive. It's not double caching, it's layers of caching. The kernel caches inside kernel memory space, sure, but you still need a syscall to reach that. Every application has layers of caching, it's very normal. This isn't even the top layer of cache, because of course the CPU itself has multiple caches.
But, for example, in a web application you will commonly cache requests. But then the database also has a cache. And then the filesystem the database is on also has a cache.
> I think any empty Qt/GTK app eats 40 MB at least.
Classic GTK is (much) better (RSS on Linux):
Once it was decided that a desktop application must have fancy animation effects (like on smartphones) and be rendered completely on GPU things got very different:
GTK used to be considered the bloated option along with QT. My first Linux box had 128MB of ram and it was screaming fast.
At one point I ran graphical linux on a 20 mb ram laptop although admittedly that was very tight.
I also remember running nt4 with photoshop, word, and my IDE (borland delphi) all at the same time and comfortably in 128 mb of ram.
What was the lean option?
These apps have codebases going back to the 2000s when having 256MB ram total was a big deal, yet these apps could contend with that (while offering pretty much identical functionality). I remember one of the big arguments for GTK against Qt was that C++ relied heavily on templates, thus every C++ app would have their own copies of the same functions in RAM, while GTK was C, and a lot of those library pages could be shared. Qt even did some nonstandard tricks to cut down on this duplication, which was unpopular with the C++ people.
My Windows 98 install got ten times faster when I went from 32 MB of RAM to 48 MB of RAM.
A fresh boot of my Windows 98 install at the time, once everything was loaded and settled, used up 27 MB of RAM, meaning that after 5 MB of allocations someone was getting paged out somewhere. That extra 16 MB made a world of difference.
Do bear in mind, though, that we're dealing with a lot more than we were back then. Our hardware is more complex, with more and more complex drivers needed to manage more things. Accessibility is different, screens are larger (my monitor now has 27 times the pixels as my monitor then) meaning more memory required for larger textures which are now composited in hardware rather than re-rendered every frame.
I agree with others that things are ridiculous these days, but it's also easy to see that our expectations also need to adjust somewhat. Still, using a webview for displaying the weather... I get why they do it, but it's a scourge. It's emblematic of their care for the customer, which is nonexistent.
Casey Muratori has complained about the hardware driver overhead, because it is possible for hardware to have standard interfaces without needing a device-specific software translation layer, especially for more basic modes (like framebuffer).
AFAIK, Qt's C++ extensions (moc, meta-object compiler) have nothing to do with how it reduces template bloat from containers, which is by moving some type-independent implementation parts to shared methods.
In the 2000's 256MB were the bare minimum, my PC in 2002-3 had that.
> mpv --idle --force-window 160 MB
That's still a HUGE amount when you remember mplayer (which mpv was based on) ran on PCs that has had less RAM than that.
Yeah, most of modern Linux wastes memory too. 100MB for a blank OpenGL context? Ridiculous.