Desktop Environments Resource Usage Comparison

https://vermaden.wordpress.com/2022/07/12/desktop-environments-resource-usage-comparison/

by vermaden • 4 years ago

86 84 4 years ago

vermaden.wordpress.com

dijit2• 4 years ago

I shouldn’t be surprised, but desktop environments using >1G of ram as standard strikes me as insane.

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?

corrral3• 4 years ago

I feel similarly about Windows. Way, way more resource hungry. Tens to hundreds of times, depending on the metric. Barely does more than Win95, as far as user-facing features. Shit I bet most of the important features would have fit in 5-10MB of "power tools" addons with barely-measurable effects on memory and cycle use. Win95 ran very comfortably on 64MB (with an M) of memory and a 4GB disk. You can't even install the OS on a disk that small anymore, let alone have room left for anything else.

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.

AnIdiotOnTheNet• 4 years ago

What hardware giveth, the software developer take the away. For a variety of reasons, today's devs are terrible at writing software that is even remotely efficient.

lambdaba• 4 years ago

Win95 ran very comfortably on 64MB (with an M) of memory and a 4GB disk.

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!

ChuckNorris896• 4 years ago

I feel similarly about Windows. Way, way more resource hungry. Tens to hundreds of times, depending on the metric.

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.

ssivark• 4 years ago

I wonder how much of that comes from careless programming (accidental complexity), and how much is essential complexity in keeping with user expectations for polish & responsiveness (driven by Apple, etc).

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.

citrin_ru• 4 years ago

When not much resources available one have to be more careful (about not accidentally creating O(N^2) where O(N) would work and not wasting RAM on multiples copies of the same data) and at same time one have to refuse adding non essential features with bad HW resources / user value ratio.

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.

layer8• 4 years ago

my first custom built PC had 1G of memory for the entire system

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. ;)

waterlaw• 4 years ago

A Spellchecker Used to Be a Major Feat of Software Engineering
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 ;)

juunpp• 4 years ago

When you feel your desktop is too heavy, bury your woes by firing a web browser.

pmontra• 4 years ago

I started using Ubuntu 8.10 with Gnome 2 and Compiz on January 2009. I've stopped thinking for a while what I'm getting with Gnome 3 on Ubuntu 20.04 now that I didn't had in 2009. The only important feature I came out with is gsconnect / kdeconnect which maybe would have been impossible with Gnome 2 but maybe not. Everything else feels like nice to have small esthetic improvements which I would do without if I think all the time I had to spend configuring out all the new stuff I didn't like. I used Gnome Flashback until the upgrade to 18.04, when I was sure I could put together a dozen Gnome shell extensions to get a desktop I could live with. Switching back to Windows or to a Mac with the OSX GUI would have been worse for me. Tastes.

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."

maccard• 4 years ago

In 2005 my resolution was 1024x768 on a 60(?)Hz screen. That's 2MB per frame. Right now I have 2x 2560x1440 HDR monitors with 144Hz refresh rates hooked up to my machine, with double buffering is 100MB just for screen buffers. I believe it was Windows Vista (apologies I'm not confident in my linux versions) that introduced the DWM compositor, meaning that all of a sudden you need all of the frames of all of the windows in memory x 2.

intrepidhero2• 4 years ago

Recently I was looking at DEs on Debian 11 and measured their relative number of installed packages. My reason was to get a first order approximation of "vulnerability surface" based on the assumption that more packages would probably imply more things to have vulnerabilities. I realize that's a gross oversimplification but I thought it was an interesting metric.

  DE       Added packages
  Plasma:  964
  XFCE:    417
  Openbox: 103

Of course Plasma (and XFCE) give you way more functionality than OpenBox, and I found if you start installing other programs to replace all that (Network Config GUI, USB storage GUI, file manager, etc) you quickly start to approach at least XFCE levels of packages. Still I found it an interesting exercise. You could start with openbox and potentially make better choices, choosing more secure programs (for some measure of secure). Or assume that because Plasma has more developer energy behind it and therefore get security updates much faster.

It's nice to see number of packages and RAM usage correlate. That seems intuitive at least.

melissalobos2• 4 years ago

I realize that's a gross oversimplification

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.

TingPing• 4 years ago

XFCE does have modularity in many ways. The reality is it has a tenth of the complexity of Plasma.

lmm• 4 years ago

My reason was to get a first order approximation of "vulnerability surface" based on the assumption that more packages would probably imply more things to have vulnerabilities.

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.

melissalobos2• 4 years ago

A lot of these types of comparisons done with distribution provided packages aren't really ever comparing what they think they are. KDE has a TON of components which can be optionally compiled/installed(like baloo or the PIM), which are not essential and offer features far beyond what a regular XFCE install will provide(and which most non-corporate users don't want). In addition there are lots of different flags and ways to compile each of these environments(and their related libraries) that can make all of them much leaner if that is the goal.

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.

Lerc3• 4 years ago

I feel like it's gotten too hard to judge the size of gigabytes of RAM.

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?

sidpatil• 4 years ago

Where'd you get the 3 from? I thought it'd be 24 or 32, since that's how many bits you'd need to represent the color.

Lerc3• 4 years ago

3 bytes. 24 bit.

cperciva• 4 years ago

In the context of games: There's a lot of space used for high resolution textures which users normally never see... but they can see if they zoom in, put their nose up to a wall, etc.

Jasper_2• 4 years ago

So, to start with, 1920x1080x4 -- even if the alpha channel isn't used, we align to pixels 4-byte words for performance (if you want to trigger panic quickly in a crowded room full of Linux graphics developers, say "Cirrus 24-bit shadowfb" out loud and see how quickly you get thrown out of the room).

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.

Lerc3• 4 years ago

You've mentioned a bunch of stuff, but even then the numbers don't add up double and triple buffering are adding just another few buffers per screen. Multiple buffers for every window still doesn't add up to the memory use levels some of these desktop environments use. 50 maximized windows with multiple buffers still ends under a gig.

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.

intrepidhero2• 4 years ago

I'm running Plasma on a couple of repurposed Chromebooks: Celeron 2 core @ 1Ghz with 4GB of RAM and the DE is quite snappy. Inkscape, GIMP and the Godot IDE have run great. Light gaming: minecraft on somewhat reduced settings, older windows games on Wine, terraria, and stardew valley all fine.

Anything in a browser? Horrible.

anthk• 4 years ago

Use UBo in the browser. Also, chrome based browsers have a --light switch.

mise_en_place• 4 years ago

explorer.exe is 347 mb memory usage in comparison. We really are in the year of the Linux desktop, those DEs are bloated like Windows used to be

HKH2• 4 years ago

Windows is still bloated.

encryptluks22• 4 years ago

Lol.. Windows desktop runs a lot more than explorer.exe.

approxim8ion• 4 years ago

explorer.exe is closer to a window manager than a desktop environment. you'd have to compare it to kwin, mutter, xfwm, or i3.

codedokode5• 4 years ago

1) The post has problems with math and the numbers are wrong

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.

anotherhue2• 4 years ago

Not really the 'same' (but good enough (better in fact) for me): Sway comes in under 40MB of RSS.

Kaze404• 4 years ago

Sway is a window manager, not a desktop environment. Not a fair comparison, since you have to install everything DEs provide separately.

anotherhue2• 4 years ago

No doubt, but I do challenge the assumption that you need 'everything'. I get by pretty well with about 20 apps and DEs tend to just keep adding more and more.

aidenn0• 4 years ago

I closed everything that was using more ram that plasmashell on my machine and ended up with about 3.3GB of memory usage (down from 12ish, mostly firefox, but evolution and MS teams were also pretty ram hungry).

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.

pca006132• 4 years ago

Interesting, I'm using KDE Plasma as well, and with only a terminal open, my RAM usage is about 1.25GB, and < 3GB with Firefox opened (I don't open a lot of tabs though).

adamzegelin2• 4 years ago

Isn't summing RSS going to end up with the wrong numbers?

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.

adamzegelin2• 4 years ago

Just a quick experiment:

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

Summing RES (RSS) gives 298744.

VLC loads many shared libraries:

    $ lsof -p 1806426 | grep .so | wc -l
    195

I'd hope some/most of those are shared between the instances of VLC and are included in SHR (if I'm reading the top man page correctly).

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.

vbernat• 4 years ago

On Linux, you also have PSS which is like RSS, but the shared part is divided among the processes sharing the same memory.

codedokode5• 4 years ago

SHR is not "shared" size, it is "potentially shareable size". Process might have 100 Mb of SHR and none of them actually shared.

You should use PSS which accounts for shared memory pages (by dividing their size across all processes).

grahamjperrin2• 4 years ago

… RES (RSS) …

If RES is resident memory <https://www.freebsd.org/cgi/man.cgi?query=top&sektion=1&manp...>, what's RSS?

codedokode5• 4 years ago

You are right. RSS values cannot be added. Imagine if there are 3 processes, each use 100 Mb of shared memory and 100 Mb of private. Summing the RSS we will get 200 + 200 + 200 = 600 Mb, however the true memory consumption is 100 (shared) + 100 + 100 + 100 = 400 Mb.

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.

encryptluks22• 4 years ago

I use Sway and it definitely is a lot faster than Gnome or KDE. KDE is more of an ecosystem though. Installing any package on Arch that has some dependency on KDE wants to pull in a bunch of large dependencies.

tvb12• 4 years ago

Could you not use htop for this? I was kind of surprised when it showed i3 using about 500mb while pretty much idle. I do have a few extras installed: lxpolkit for mounting with nautilus, feh for a background, nm-applet, picom, etc. There weren't any big whales, either. All of the processes were using only a point or so of ram.

checkyoursudo2• 4 years ago

My i3bar is using 162MB, but I use a pretty extensively customized py3status. The /usr/bin/i3 executable itself reports not even a couple hundred KB for me.

ninjin• 4 years ago

A couple hundred KB is very impressive for i3. Even the ridiculously minimalist dwm (with a few patches applied) clocks in at 15,000 KB on my desktop. It does ship with a status bar though.

saturn5k• 4 years ago

Just for reference, I am using KDE Neon 5.25 and cold boot mem usage is around 800 megs. I'm not sure how the author got his numbers, but something is way off.

pleb_nz2• 4 years ago

Agreed, something really off here. I used fedora plasma until 2 months ago and on boot it was always less than 1Gb. Once I started ides and things like intellij then I would see ram usages in the 2 to 3 gbs.

stock_toaster• 4 years ago

What do you use now?

ChuckNorris896• 4 years ago

Same, I did an install with OpenSUSE Tumbleweed and the latest KDE desktop environment with all optional packages and goodies, and after a fresh boot into KDE with Konsole opened, the RAM consumption was from 580MB to under 760MB, similar to XFCE.

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.

nix234• 4 years ago

You are checking with htop right?

prmoustache• 4 years ago

I am pretty sure is numbers are skewed by summing RES which include for each process the shared memory. So he is basically summing things that shouldn't be summed.

unicornporn• 4 years ago

Sameish numbers here. I thought KDE doing just as good (and even slightly better) than XFCE (in the RAM department) was kind of a well established fact at this point.

alpaca128• 4 years ago

Most numbers seem too high to me. KDE and Gnome are definitely below 2GB out of the box and Openbox using >600MB also seems pretty high. A lightweight system like Alpine or Void can be at ~150MB of RAM usage with a window manager.

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.

badsectoracula• 4 years ago

These numbers are bad because they are not really about what desktop environments use but about what the entire OS will use since they rely heavily on the OS configuration for that.

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.

codedokode5• 4 years ago

Ignoring X server (or Wayland) is wrong because desktop environment can allocate memory in X server's process and it won't be accounted.

ladyanita22• 4 years ago

I must say I was looking for an update on this. It is absolutely fantastic to that someone is taking the time to do this. Thank you so much!

Edit: Ok, no, those numbers are totally off.

vermaden2• 4 years ago

Just added freecolor(1) and htop(1) RAM measurements at the end.

Hope that helps.

Regards.

Fnoord• 4 years ago

"Desktop Environments Resource Usage Comparison" [...] on an OS practically nobody uses for desktop, FreeBSD. I cannot use this comparison, since I don't use FreeBSD for desktop.

KronisLV• 4 years ago

Someone actually tried doing that across various Linux desktop distros a while ago: https://www.reddit.com/r/linux/comments/5kdq92/linux_distros...

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.

bigpeopleareold• 4 years ago

A very unscientific and anecdotal comparison of KDE Plasma on Kubuntu 22.04 and my install on FreeBSD at the very moment I am looking at both: the memory usage seems similar overall, but individual processes seem oddly different. Example, kded5 on kubuntu (kde version 5.24.4) is using ~57 MB of memory, on FreeBSD (kde version 5.24.5) uses ~112MB. For kwin_x11, ~61MB on kubuntu, 140MB on FreeBSD. I restarted Xorg on FreeBSD and that's what they booted up to.

This is interesting why it uses a bit more memory on FreeBSD, but there is probably some reasoning behind it.

vermaden2• 4 years ago

Take a look at the end of article where I added also freecolor(1) and htop(1) memory usage - it seems to be a lot lower then RSS field from top(1) command.

afarviral• 4 years ago

Ive mostly just used LXQT with my favourite file manager nemo and called it a day. I dont see the appeal of heavy DEs. Openbox has ludicrous customization potential for basic split views and keyboard navigation, and endless visual tweaks and themes too, dmenu for launching stuff. What is the stuff that you'd miss from kde/cin/gnome?

codedokode5• 4 years ago

These numbers seem completely wrong to me. You cannot add RSS, you should add PSS (proportional set size) and SWAP PSS to obtain true numbers. PSS values allow to account shared memory properly.

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...

zarski• 4 years ago

fwiw: I just put Bodhi Linux v6 (Enlightenment/Moksha) on a Macbook late 2011 model that has 16GB of RAM and a SSD. It is now running great under Bodhi but was butt slow with Ubuntu 20.04.

Desktop Environments Resource Usage Comparison

Related Stories