Linux Mint MATE vs Xfce: RAM usage

Hi all, :wave:

as I´m still looking for a new (resource-friendly/lightweight) distro for a new installation I came across this article:

Dimitrios is taking a closer look at the differences of the 3 DEs used in Linux Mint.

If Linux Mint was a potential candidate then I´d discard cinnamon, which would leave me with MATE and Xfce then.

I´m taking Mint into account as of late because I discovered Linux Mint MATE was using just around 460 MB of RAM after a fresh boot when I tested it on distrotest yesterday. :wink:

Now back to the link I mentioned above.

Dimitrios says:

Briefly, the available choices are the following:

Cinnamon desktop: A modern touch on traditional desktop
MATE desktop: A traditional looking desktop resembling the GNOME 2 era.
Xfce desktop: A popular lightweight desktop environment.

So far, so good.

For “MATE”:

  • MATE desktop has a reputation of its lightweight nature and there is no doubt about that. […]
  • it doesn’t feel as snappy as Xfce (in my opinion) […]
  • RAM consumption starts under 500 MB which is impressive for a feature rich desktop environment.

For “Xfce”:

  • It aims to be fast, lightweight and easy to use […]
  • Xfce is the leanest desktop environment Linux Mint has to offer […]
  • Very lightweight – suitable for older hardware […]
  • Rock-solid stable […]
  • At the first boot the ram usage is similar to MATE desktop but not quite as good. # how can that be :question: :astonished:

It´s the last statement that took me by surprise. How is it that RAM usage with Xfce isn´t “quite as good as” with MATE :question:

I would´ve thought it was the other way round. :thinking:

Taking a look at the screenshots Dimitrios provided these are the values for …

MATE: 464 MB
Xfce: 504 MB

All measured with htop after boot.

Contrary to my assumptions it would look like Linux Mint MATE would consume less RAM than Linux Mint Xfce. :thinking:

I´m very interested to learn what you think about it.

Thanks a lot in advance.
Many greetings from Rosika :slightly_smiling_face:

P.S.:

On my (installed) Lubuntu htop says: 492 MB RAM usage after boot with nothing else running.

Hi Rosika,
I think Xfce comes with more things installed by default than does Mate. Comparing ram usage fairly is difficult. Another way is to compare the download size of packages. I did that a while back, I will look it up.

I feel quite comfortable with either Xfce or Mate. They are both good dte’s.
You can always remove a dte from any Linux, and install another, if the default does not suit, but it is certainly safer and easier to use what comes with a distro.
Regards
Neville

1 Like

I wouldn’t trust some people writing such articles. You should try this all yourself, especially since you play around with VMs a lot, anyway.

When it comes to such hugely complex pieces of software like operating systems, you cannot make a general assessment about its performance beyond “it’s relatively lightweight” or “it’s relatively heavy weight”. It’s most of the time near impossible to make sure the RAM usage does not vary between machines. Therefore, again, you should try it out. Perhaps your results are very different, who knows.

Additionally, what apparently has to always be repeated like a mantra, because too many lightweightness freaks forget about that fact weirdly:

RAM usage is not RAM usage.

There is no “RAM usage”.

There is RAM that is actually in use by software right now (coming closest to the original meaning of “RAM usage”), but there is also cached RAM, reserved RAM, etc.

So, if people talk about RAM, they should always be aware, that comparing RAM usages between machines can become precarious super quickly. You have to be very precise about this topic, or the results will simply be completely wrong.

…which is again another reason, why I wouldn’t trust such article. Just try it out yourself and be aware of what “RAM usage” actually means.

Thirdly, less RAM is not always “better”. Less RAM usage sometimes means, the operating system is not very efficient (not the case nowadays, mostly). A good operating system will use as much RAM as possible, to make the OS run as smooth as possible.
Which is a fact again pointing at how it is extremely important to look at the different types of “RAM usage” that is available.

There are too many Linux people saying “Windows is using too much RAM, etc.”, which is often (not always) just utter non-sense. Of course, it’s gonna use more RAM, if you have so much available. Why buy the RAM if the OS never uses it?
It is smart to use a lot of RAM, if lots of RAM is available. It would be stupid to keep it “empty” just so lightweightness freaks can look at the Task Manager and let out a satisfactory sigh with a glass of wine in their hands.

So, I’ve explained the general problem with RAM and how many people (not you) confuse the RAM situation so much, it becomes ridiculous, sometimes.

Based on that explanation, I would strongly recommend, that you make your own tests on your own machine, with your own programs etc., to see what is happening. And even then, you still have to be very specific about what type of “RAM usage” you are looking at. Reserverd? Cached? Actually in use?
If 80% of the RAM is reserved or cached, which might seem “used”, that’s a good thing, not a bad one!

3 Likes

Hi Neville, :wave:

thanks for your kind (and very quick) reply. :heart:

O.K., I looked it up:

  • for Xfce:
firejail wget --spider "https://muug.ca/mirror/linuxmint/iso/stable/21/linuxmint-21-xfce-64bit.iso"
Spider mode enabled. Check if remote file exists.
--2022-08-02 14:34:26--  https://muug.ca/mirror/linuxmint/iso/stable/21/linuxmint-21-xfce-64bit.iso
Resolving muug.ca (muug.ca)... 2605:e200:3:4::244, 208.81.1.244
Connecting to muug.ca (muug.ca)|2605:e200:3:4::244|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2415585280 (2,2G) [application/octet-stream]
Remote file exists.
  • for MATE:
firejail wget --spider "https://muug.ca/mirror/linuxmint/iso/stable/21/linuxmint-21-mate-64bit.iso"
Spider mode enabled. Check if remote file exists.
--2022-08-02 14:36:51--  https://muug.ca/mirror/linuxmint/iso/stable/21/linuxmint-21-mate-64bit.iso
Resolving muug.ca (muug.ca)... 2605:e200:3:4::244, 208.81.1.244
Connecting to muug.ca (muug.ca)|2605:e200:3:4::244|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2510614528 (2,3G) [application/octet-stream]
Remote file exists.

So you´re right: 2.2 GB (Xfce) vs. 2.3 GB (MATE). :+1:

Quite.
I once tried that in a VM.
Had BodhiLinux installed at the time (it came with Moksha) anf then added LXDE as a second DE.
I never ran into any difficulties; it worked fine at the time. :wink:

Thanks a lot and many greetings
Rosika :slightly_smiling_face:

2 Likes

Hi @Akito, :wave:

thanks so much for your very detailed account of what RAM usage means. :+1:

I see… Well, I was thinking, as the article is from ITSFOSS (itsfoss.com) there´s ceratinly some quality behind it…

Right. I may start a live session and take a closer look at it.

Yes, I get that.
But Dimitrios, the tester, was certainly making use of the same machine for testing purposes and did the tests by providing the same condidtions.
… i.e. doing a fresh boot, running nothing else than htop for measuring purposes.

Still there seems to be MATE slightly ahead of Xfce. That´s what surprised me to a certain extent.

Yes. Thanks.

Here´s the output of my current session:

env LANG=en_GB:en free -m
              total        used        free      shared  buff/cache   available
Mem:           3850        1748         263         421        1837        1431
Swap:          1023          12        1011

If you don´t mind my asking: I can see “cached” but where can I see “reserved RAM” here?

Yes, that´s plausible. Thanks.

As I still have an older Linux Mint (Xfce) ISO lying around (linuxmint-20.2-xfce-64bit) I guess for testing purposes I could put it on my ventoy stick and give it try.

Thanks so much for your help @Akito . :heart:

Many greetings
Rosika :slightly_smiling_face:

Yes. Same conditions on his end, but not the same on yours. Especially, after adding software, etc.

During my search for that answer, I’ve found the following answer on a bit different topic.

Be aware though, that this answer can become confusing. What is said here about unused RAM etc. is targeted toward developers. Additionally, one could interpret cached RAM as lost, when reading the answer. Though, cached RAM is what makes things run smoother overall.

Anyway, the most important quote from the answer is the following.

You’re hitting the infamous “Out of Memory” (OOM) bug. This has gone for more than 16 years, and it’s only since mid-2019 that this bug is getting attention… without any reliable fix since. This is due to Linux bad habit to cache things, overcommitting way too much RAM and unability to tell how much unreclaimable cache/buffers you really have.

Regarding the original question, as to how to determine reserved RAM, I’m not sure how exactly to interpret what Linux is saying about RAM. This is what I found about the topic.

Though, a better test would be to have the latest image available. Sometimes, performance can change a lot between releases.

Maybe you can visit a café with free Wi-Fi to get that? :smiley:

1 Like

Hi @Akito, :wave:

thanks so much for providing such a variety of links. :heart:

I´ve read them all, but didn´t make it completely through the fourth one yet, I have to admit :blush:.

I liked the second one most, as it provides a wealth of information using a clear and understandable language. :+1:

As far as the third one is concerned:
I noticed that my output of free -m differs from the ouptut given in the article:

Mine looks like this:

env LANG=en_GB:en free -m
              total        used        free      shared  buff/cache   available
Mem:           3850        1968         285         433        1596        1203
Swap:          1023          25         998

whereas theirs look like this:

free -m
             total       used       free     shared    buffers     cached
Mem:          2026       1922        103          0        491       1109
-/+ buffers/cache:        322       1703
Swap:         4094          0       4094

So I don´t get this line:

-/+ buffers/cache: 322 1703

However I can employ the wide-mode:


env LANG=en_GB:en free -wm
              total        used        free      shared     buffers       cache   available
Mem:           3850        1972         276         438         171        1430        1195
Swap:          1023          25         998

man-pages:

In this mode buffers and cache are reported in two separate columns.

I guess the site is using an earlier version of free as the article dates back to mid-2012.

The fourth source also refers to smem, which I had installed on my system quite a while ago. I found that interesting indeed. :wink:

No can do. :blush:
Living in the middle of nowhere with no such sophisticated infrastructure around anywhere it´s not doable. But …: see below.

Right.
Although I cannot download a respective ISO at the moment I´ll have to do that in the forseeable future.

2.2 or 2.3 GB download isn´t within my reach right now. For that I have to switch over to AldiTalk´s “Datenpaket L” (one time only, I hope :wink:) which gives me 10 GB per 28 days (for a higher cost of course.)

Thanks again @Akito for helping so much with your essay, links and tipps. :heart:.

Many greetings from Rosika :slightly_smiling_face:

One of my biggest bugbears with shonky alerting systems triggering P1 or P2 incidents and service desk waking me up at 3:00 am! FFS! It’s A GOOD THING it’s using all its RAM, we didn’t overprovision which is a waste of money!

Then the alerting system needs to be fixed. Not sure about legacy systems, but, for example, if there is a RAM pressure notification coming from Kubernetes, it’s actually real and not just a misunderstanding.

Additionally, you can define very precise resource assignments to each deployed piece of software. So, if you put in some reasonable amount of time & effort in hardware resource management before going production, you will never get an issue, at all. And even if there would be an issue, it would not be an unnecessary alert.

Therefore, the alert system your contractor (or whoever) is using needs to be fixed or replaced or recalibrated. :smiley:

Hi again, :wave:

after having dealt with the topic of RAM to quite some extent now I see there´s no easy way to compare different distros based exclusively on that. :neutral_face:

Yet it certainly was an interesting excursion (especially in view of what smem can display).

Nevertheless - and in spite of what the title of the topic suggests - I still wanted to try a comparison of at least some of the distros I have lying around as ISOs.

In order to arrive as close as possible at a more or less fair comparison I powered up three distros in a VM:

  • all not installed but as a live session
  • all using the same command with the same settings for the VM
  • nothing else started after boot than a terminal and running top -i for comparison

The distros (or rather ISOs)I used are:

  • lubuntu-20.04.1-desktop-amd64.iso
  • linux-lite-4.4-64bit.iso
  • linuxmint-20.2-xfce-64bit.iso

Haven´t got LinuxMint´s MATE version available yet. So the Xfce version is used instead.

The command I used is the following (example for LinuxMint):

firejail kvm --cdrom /media/rosika/Windows8_OS/Users/rosalia/Desktop/neue_ISOs_und_anderes/für_LinuxMint/linuxmint-20.2-xfce-64bit.iso -cpu host -m 2048 -boot d

so I assigned 2 GB of virtual RAM to all of the machines.
I took screenshots of the VMs to see what top -i has to say. :blush:

For anyone interested here are the results:

Lubuntu:

Linux Lite:

Linux Mint:

Just taking a look at the “used” output:

  • Lubuntu: 285 MB
  • Linux Lite: 331 MB
  • Linux Mint Xfce: 368 MB

The outcome would reflect what I was guessing beforehand.
I haven´t taken into consideration the other fields like “buffer / cache”, just “used”.

If that´s anything I can go by it seems of the three Mint still would be “heaviest”. :thinking:

Perhaps it´s still worth considering…

Many greetings from Rosika :slightly_smiling_face: