Desktop Environments Resource Usage Comparison
vermaden.wordpress.com
vermaden.wordpress.com
I get that they’re doing a lot but my first custom built PC had 1G of memory for the entire system (and that was absurdly large by those days standards; somewhere around 2005).
I don’t see terribly large improvements in functionality between 2005’s gnome2 and what exists now in mate or XFCE, bearing in mind that I was playing with beryl/compiz at the time too.
Does anyone know what’s contributing?
As for Linux, I remember using Windowmaker for a long time, and later XFCE, because Gnome and especially KDE (funny how those have reversed position performance-wise now, eh?) would make my poor Celeron laptop cry. But they did run, and didn't even come close to maxing out my 384MB of RAM in that machine.
I ran it on 8mb ram / 850mb disk. Did upgrade to 16mb ram and the performance boost was palpable, but, again, used it at 8mb for a while. Also a fresh install took up a whooping 50mb!
> Also a fresh install took up a whooping 50mb
I do wonder WTF modern Windows is doing with tens of GB of disk space, not even counting swap & such. Seems like it jumped up dramatically after WinXP—even the otherwise-kinda-decent Win7 used crazy amounts of disk. "They started including a bunch of drivers" bullshit, Linux has always included loads of drivers with most default installations and it's so much smaller that just calling it "smaller" doesn't do the difference justice, plus there are surely a lot of those that could easily be made a download or optional default-off package (extremely niche or very old hardware).
You're incorect here as that's not an apples to apples comparison. If you've got the RAM, Windows (and MacOS too I bet) does a lot of caching on boot of frequently used apps and files to RAM, as any sane desktop focused OS should do to give you a good experience, and it frees it back up as it starts to be needed by other apps. If you've got free RAM, why shouldn't the OS put it to good use to improve the UX?
I never understood the obsession of many enthusiasts, to spec PCs with huge amounts of RAM, then smugly compete for the least amount of idle RAM used by their system. That's not the metric of a good desktop OS. What do you gain by just staring at large amounts of RAM that you paid for just sitting idle and unused by anything? RAM is there to be used, and if free RAM is available and the OS is smart about using it and freeing it on the fly to boost the UX, then please by all means go ahead and use as much as you want if that will improve the UX.
My parents run Windows 10 on my 11 year old 4GB laptop with a spinning rust drive, using Chrome as a browser and it works without ever crashing or needing to kill apps, so IMO, Windows is stellar at managing memory/resources even when in very short supply. Meanwhile on the same laptop, Ubuntu's Gnome would just completely lock up after a long Chrome browsing session, or its OOM would just straight up kill Chrome, both cases yielding a much worse UX than on Windows, making it the far superior desktop OS in this case.
IMHO a better and more realistic metric should be idle CPU usage, and how the OS deals with low memory scenarios, like the one I described above, not by how little idle RAM it uses on PCs with large ammounts of it as that's just pointless.
"Why" is the question here. New cars don't use more petrol. And new bikes are not heavier then old ones.
I believe it is the same in windows and MacOS too.
So “used ram” from the OS perspective cannot be reused as filesystem caches.
I doubt they’re increasing performance either as the overall performance of such a system is so low.
it’s also hard to argue increased performance when your app could have instead fit in L3 cache.
I absolutely do not think intelligent caching is behind enough of the increased memory use to absolve them of all the waste. I don't believe Microsoft are being more respectful of memory than they are of other system resources. It also fails to explain the huge increase in memory footprint of Linux desktop environments and window managers. I don't think XFCE is caching your most-used "apps" in memory at launch.
Another possible source of the problem I can imagine might be the ubiquity programming style of using high-level languages and important libraries on a whim. If the language does not strip out unused code paths in dependencies, sizes can quickly add up with the same libraries being reimported multiple times.
In corporate software it is often easy to find some low hanging fruits allowing to reduce CPU/RAM usage by 10x (but incentives stacked against doing this). In open source software like KDE/Gnome I think it would be hard to find blatantly inefficient code and the main reason is the overall complexity which is hard to reduce without sacrificing some features.
Windows 95 ran on 4 MB, and very well on 8 MB. I believe I ran Linux with fvwm2 on 8 MB as well.
Of course 64-bit and higher resolution increase RAM requirements to some degree, but I’m still not sure what Openbox needs 600 MB for. ;)
> Fast forward to today. A program to load /usr/share/dict/words into a hash table is 3-5 lines of Perl or Python, depending on how terse you mind being. Looking up a word in this hash table dictionary is a trivial expression, one built into the language. And that's it. Sure, you could come up with some ways to decrease the load time or reduce the memory footprint, but that's icing and likely won't be needed.
https://prog21.dadgum.com/29.html
5MB here. 5MB there. No one notices ;)
Then there is the inevitable maintenance to keep the desktop environment compatible with the world that is changing around it. Kernels, drivers, etc. "It takes all the running you can do, to keep in the same place."
My understanding is that RSS is memory allocated (heap + stack) + executable pages inclusive of shared libraries.
i.e, if 10 processes load libfoobar which is 10MB of code, each processes RSS value will be 10MB higher. So if you sum RSS you see 10 x 10MB or 100MB extra usage. But the pages for that library will be shared across processes, with the result that "real ram usage" only goes up by 10MB.
Please correct me if I'm wrong. This is based on my understanding of Linux too. FreeBSD might be different.
I started 4 copies of VLC. `top` shows this:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1806287 adam 20 0 1091068 74664 56228 S 0.0 0.2 0:00.22 vlc
1806426 adam 20 0 1091064 74548 56128 S 0.0 0.2 0:00.21 vlc
1806537 adam 20 0 1091064 74572 56144 S 0.0 0.2 0:00.22 vlc
1806600 adam 20 0 1091064 74960 56536 S 0.0 0.2 0:00.23 vlc
VLC loads many shared libraries:
$ lsof -p 1806426 | grep .so | wc -l
195
Doing RES-SHR isn't totally correct either. Those shared pages might be "marked as shared" (i.e, a .so that's only loaded by one process). But lets assume that most of what VLC uses as SHR is shared libraries, and they're used by each instance.
RES-SHR = 73708
I also ran `free` before and after launching the 4 instances of VLC. Used increased by 66068. Hard to rely on the accuracy of this number since this is a desktop system and I'd imagine used goes up and down all the time. But it's strikingly close to the RES-SHR figure.
IMHO just summing RES isn't correct.
Linux memory usage is complex.
You should use PSS which accounts for shared memory pages (by dividing their size across all processes).
If RES is resident memory <https://www.freebsd.org/cgi/man.cgi?query=top&sektion=1&manp...>, what's RSS?
To count the memory properly, you should divide size of shared segments by number of processes using it. This is how PSS in Linux is implemented. You can safely add PSS values of different processes. If you have swap, you should also sum swap usage by processes.
As I understand, you can reliably count memory usage only in Linux because other OSes like Windows or Mac do not provide PSS in their Task Managers. Windows Task Manager at least has a documentation that describes what "memory" column means, and I failed to find such documentation for Mac, so we can safely assume that it displays random numbers remotely related to memory usage.
DE Added packages
Plasma: 964
XFCE: 417
Openbox: 103
It's nice to see number of packages and RAM usage correlate. That seems intuitive at least.
In part especially since KDE deliberately breaks up their core libraries into multiple sub-libraries(https://develop.kde.org/products/frameworks/), in order to make them available for reuse by other Qt projects. Which is not the case for XFCE. KDE also depends on Qt which is similarly broken up into smaller packages(e.g. https://packages.debian.org/buster/libqt5gui5 is depended on by https://packages.debian.org/buster/libkf5auth5). Even though the actual attack surface in terms of exposed functionality is similar.
Hmm, I'd think the opposite - DEs with a large number of dependencies are probably well factored and following good development practices, DEs that are a giant blob of undifferentiated C would seem much more likely to have vulnerabilities.
Nice hardware, but I miss Linux everyday.
I don't know how the author got those huge numbers but I fell like something is off with his FreeBSD installation/configuration and is skewing the results.
I'd take those results with a huge boulder of salt.
RAM usage comparisons including the whole OS aren't that interesting imho, run a couple programs and you'll never reach those numbers again until the next reboot. RAM isn't intended to be empty.
A much better approach to check how much resources DEs use is to capture the memory use before and after the DE itself starts, ignoring even X server (as this too can use different memory depending, e.g., on the drivers, hardware and/or other configuration parameters - all of which are outside the control of a DE).
As an example by placing `free > free-pre` in my .xinitrc before starting Window Maker and then `free > free-post` at the end of Window Maker's own startup script (which is run after the desktop is launched) i found that my WM setup uses 11MB of RAM (on a 64bit x86-64 machine - it'd most likely use less on a 32bit machine). This is however also on my setup where i have a bunch of dockapps launched that aren't part of a default Window Maker installation - disabling those puts the resources Window Maker needs down to 8MB of RAM.
These are way more realistic for Window Maker (and basically what i'd expect it to use) since my OS (openSUSE) at startup uses around 3% of my available RAM (32GB) and i'm certain that Window Maker doesn't need 1GB of RAM to work - which makes sense since pretty much all of that is used by other processes, like systemd, postgres, bunch of managers, etc.
A fairer comparison would be to look at the most minimal install with similar compilation flags, or look at only what applications it would take to achieve some goal and compile and install only those parts needed to perform it using the desktop environment's applications.
Anything in a browser? Horrible.
I come from a game development background where traditionally the bulk of the space usage went into media content. It felt easy to justify a game of X megabytes when 90% of that was in graphics. That doesn't seem to be where the space goes for things like this though.
To put this into perspective, the calculation I make is 1920x1080x3 (an uncompressed HD screen) = 6220800. Roughly 6 megabytes. That makes a gigabyte hold 170-ish full screens of uncompressed graphics. I'm ok with something using a gig if it's throwing that much imagery around, but if not, where does all the space go?
But not only that -- for compositing, we need to store the full window pixmap contents for each window. That's what's necessary for things like the blur-behind effect, or antialiased window corners.
But you probably want to also have tiny previews of these windows, so you're going to need mipmap'd versions of them stored. The mip chain for a texture is just the successive power-2s-down summed together, roughly an extra 33% of memory.
And we haven't even counted things like double- or triple-buffering! In order to not see tears as the GPU draws to a framebuffer, it needs a framebuffer to scan out, and a different framebuffer to draw to. So take all of the above, and multiply it again.
This is not counting all the additional bookkeeping that apps can provide. Shoutouts to SDL for only uploading a 256x256 version of window icons -- even when the game provides a 16x16 variant, SDL will internally upscale it to 256x256 before handing it to the window manager. And you probably want to display it back down at 16x16 or maybe 64x64 for your alt-tab, so that's a full mip chain on a 256x256 texture.
Oh, and window frames! On a reparenting WM under X11, you wrap the window in a slightly larger window, and draw the window frame in the larger one. So if you have a maximized window that's using OpenGL to draw, the app has its own pair of backbuffers, then you have a window frame in its own window pixmap, which the compositor then draws to its 1920x1080 backbuffer.
You probably also want a window title on that window frame, so that means a font glyph texture, but that probably fits in a single 1024x1024 R8 texture without mips.
Anyway, these things quickly add up! I've done memory profiling like this before. There's still many, many gains left on the floor, absolutely, but I've had people plug in 3 1920x1080 monitors and then complain that the window manager was using 20MB of GPU VRAM.
Mipmapping on dynamic content is just daft. If you can generate mipmaps as they change without slowing things down then you can generate them on demand when they are needed.
> Mipmapping on dynamic content is just daft. If you can generate mipmaps as they change without slowing things down then you can generate them on demand when they are needed.
We do generate the contents on demand, but mipmapping requires the texture memory be available for the full chain. In theory, you can use sparse textures on OpenGL/Vulkan, but they have several drawbacks that make them unsuitable for compositor work -- changing the mipchain configuration for a single texture can often take 1-2ms, which wasn't fast enough for our performance targets. I did the investigation!
Also there was another post on Reddit 2 years ago, where Ubuntu was used as the base OS: https://www.reddit.com/r/xfce/comments/kb0d87/i_compared_the...
Curiously, the average values for memory usage were pretty close, though more information about the methodology would be nice.
This is interesting why it uses a bit more memory on FreeBSD, but there is probably some reasoning behind it.
Notable not-kde things that were using significant ram after doing this:
Various pipeware processes, adding up to at least 100MB
systemd-journald, also about 100MB
Several things enabled to run gnome applications (dconf-service, xdg-desktop-portal-gnome, goa-daemon) also about 100MB total
One thing I noticed about plasma is how many processes there are; plasmashell is only about 10% of the usage of a plasma system doing "nothing" and it's the single largest process.
Edit: Ok, no, those numbers are totally off.
Here are the results that I got from my Linux system. I excluded all user-visible applications (like Firefox, terminal, ssh or text editor) and added up what was remanining. This includes systemd, system services like udevd, Gnome, user services like pulseaudio. Total memory consumption is 730 Megabytes (RAM + SWAP added).
I think the reasons for such high memory consumption are that Gnome shell is written in Javascript (gnome-shell alone uses 200 Mb) and there are many small daemons: for example, NTFS daemon uses 30 Mb, Xwayland uses 45 Mb, IME daemons use around 55 Mb and so on. Most daemons use somewhere around 5-15 Mb but there are so many of them that the result is this big.
For comparison, Firefox processes use somewhere around 1.2 Gb, Skype (Electron-based) uses 600 Mb, and desktop Telegram uses 600 Mb as well despite being written in C++.
If you wish to try this on your system, you can use this Python script: [1]. Don't forget to edit `get_group()` method to exclude user-visible applications (or close them). You need to run the script as root because otherwise you will be able to read only your own `smaps_rollup` files. The script also saves detailed stats in CSV format into /tmp/ram.csv.
If you don't want to use my script you can use htop and enable PSS and SWAP columns there (and you can remove useless SHR/RES).
[1] https://gist.github.com/codedokode/ddaedf4ae44cbfa16ca44dde6...
(I use st as my terminal, so I am familiar.)
2) For fair comparison you should add memory used by daemons/services, otherwise I can say that gnome-shell uses only 200 Mb which is almost twice as low as your number
3) I am not sure if you can properly measure memory usage with Windows Task Manager. You need to account properly private, shared and swapped out pages for each process.
Hope that helps.
Regards.