Comment by magackame | Hacker News Reader

Comment by magackame | Hacker News Reader

Parent Full thread

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.

> I think any empty Qt/GTK app eats 40 MB at least.

Classic GTK is (much) better (RSS on Linux):

  GTK2 14 MB
  GTK3 24 MB

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:

  GTK4 98 MB

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?

There were a number of smaller libraries closer to the X11 primitives for drawing. Motif was one that i recall which powered opencde and like environments. We had used it for an industrial control system. I ended up using fluxbox as my windows manager for a while which has its own toolkit for decorating windows and drawing menus. It was quite a bit lighter than gnome and pretty much thinly wrapped XFT (fonts), and xlib for drawing, etc.

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.

I'm pretty sure you have a plugin installed for Explorer that makes it crash - while Explorer is far from a perfect piece of software, its not even close to this bad, but it's pretty easy to extend it with COM objects that then run inside the process, that can and do crash the whole thing.

It's a work computer, and from what I see there's no visible plugins. But corporate IT always does some fuck shit (that's a technical term), so I wouldn't be surprised.

I recommend you install

https://learn.microsoft.com/en-us/sysinternals/downloads/pro...

And take a look what DLLs have been loaded into your explorer.exe. Look for non Microsoft-signed ones.

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.

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.

Reply on news.ycombinator.com