Hacker News Reader

Comment by sampo | Hacker News Reader

> If you had the hardware, would you rather see it used or see it dog slow trying to load UI components from disk?

I am willing to bet, that while Xfce uses less memory than Gnome or KDE, Xfce is also more snappy. I bet smaller memory use and snappiness correlate, while your comment is suggesting an anti-correlation.

View on HN

XFCE is a pretty snappy desktop interface, sure, however KDE is not less snappy than XFCE. I have used both more than >5 years, at the same time. KDE was on a much slower system and was not visibly slow w.r.t. XFCE. Now I'm using KDE everywhere.

The perceived slowness is due to window effects in KDE. Disable these and window appear before you lift your finger from your mouse or enter key.

Lastly, KDE's memory usage comes from the facilities it provides. Disable them if you don't need them, and save a lot of memory. KWin (window manager + compositor) uses ~180MB on a 4K screen, while file manager needs another 57. That's not much.

I did extensive testing of various desktop environments, and KDE was consistently the most sluggish of the bunch (tested across multiple devices), even after disabling all of the eye candy. The next worst is Gnome.

XFCE is snappy, but annoying due to the 1 pixel window border that you can't ever click on a high DPI display. Mate is almost as snappy and has better UX, so I use that.

If you can share your test methodology, I can reproduce your results and can see for myself.

My personal experience doesn't mirror what you have said, but sharing personal experiences do not bring us to an objective truth.

I use ALT+ (R/L) click for move resize, so I never interact with borders of windows for a very long time, honestly.

I run KDE on an old Intel NUK. It’s got 4GB RAM, 32GB SSD and a decade old i3. KDE still flies on that system.

The only time I’ve found KDE not feel responsive was in Kubuntu. I have no idea what is different about Kubuntu vs other Linux distros but the slowness in KDE on Ubuntu is down to Ubuntu and not KDE.

I've found that a barebones KDE is fast, but KDE with Akonadi and file indexing is resource intensive, especially until everything is indexed.

When baloo finishes indexing its load on processor is practically zero. Akonadi is just a centralized account management framework which works on events coming from these accounts.

Baloo uses a lot of RAM depending on what you index, but neither Akkonadi, nor baloo takes custody of the processor(s) and degrade system performance.

I decided to give KDE a shot again after over a decade running minimal window managers, and while I really like the interface, it occasionally just freezes the entire system for multiple seconds at a time. Screen stops updating, mouse and keyboard don't do anything. This is on an i7 laptop with 16 GB of memory. This never happened under StumpWM.

This is very unusual of KDE, I never experienced anything like that in the last decade. I mean, since (and including) KDE 3.5.x, yet alone 5.

plasmashell, which is written in QML (JS-based), uses hundreds of megabytes, and sometimes leaks memory or bugs out (as far as I can tell, the leaking and instability/crashing is an interaction between QML/JS, the JS engine, and KDE's C++ classes exposed to JS through bindings).

After a week of uptime, plasmashell is consuming 350MB memory (taken just now from my process manager). Considering this is my work machine and I never reboot except kernel updates, I've never seen it leak memory or crash tho. This is Debian Testing with KDE 5.26.4 w/ Frameworks 5.100 w/ Qt 5.15.

350MB is not very optimal of course. I may dig the code to see the reasons, tho.

XFCE4 had a similar memory leak ~2 years ago, which was triggered every time screen went into sleep and came back.

So, bugs & shenanigans happens, but I'm not still sure that KDE is "hell of a bloat" considering the things it provides at the speed it provides.

Checking coredumpctl, I've gotten two plasmashell segfaults in the past 4 months, and recall hangs and crashes happening more often in the past (especially under NVIDIA drivers). Additionally plasmashell has hung a few times and/or kwin terminated unexpectedly, though I think this is a Mesa bug (https://www.reddit.com/r/kde/comments/zbux1i/where_would_i_s..., https://gitlab.freedesktop.org/mesa/mesa/-/issues/7674) or amdgpu kernel bug (I've had multiple GPU driver hangs and unusable screens on sleep-wake, usually preceded by kwin dying in the same session).

I also checked coredumpctl, and no KDE related crashes logged there, hence validating my experience. Funnily, both my desktop systems run on NVIDIA cards w/ NVIDIA drivers, and both have uptime numbers in multiple months at minimum.

The personal desktop I used to use was regularly suspended to RAM and woke back, and my work system is on 7/24. Both are running KDE, and never misbehaved. They are not lightly used systems either. Also both installations use KDE extensively. Akonadi, Baloo, KIO, etc. are regularly used.

At the end of the day, this is strange.

> Disable [the features] if you don't need them, and save a lot of memory.

This is not possible in reality. https://news.ycombinator.com/item?id=24503435

It seems, the user either has some big problems on his KDE installation or looking to shared memory usage, to begin with. Let's see what I have in the same list:

    157M kwin_x11 (window manager)
    392M plasmashell (desktop shell, widgets and other on screen tools)
    175M krunner (macOS spotlight equivalent)
     30M kded5 (settings and background daemon)
     10M kactivitymanagerd (multiple activity contexts)
     40M polkit-kde-authentication-agent-1 (KDE polkit bridge)) 
     25M org_kde_powerdevil (energy settings)
     19M kdeconnectd (use mobile phone as remote control)
      5M xembedsniproxy (make tray icons work)
     13M kaccess (accessibility keys?)
     16M ksmserver (Plasma session manager)
     41M plasma-browser-integration-host (Firefox can show desktop notifications)
     10M kwalletd (password manager)
      6M kglobalaccel5 (global keyboard combos)
      5M kscreen_backend_launcher (changing screen orientation and resolution?)
      2M kio_http_cache_cleaner (?)
     32K xsettingsd (apply colour scheme to Gnome applications)
    (Some lines omitted since they are not running on my system)

On uninstalling/disabling things:

- There's background services menu, which you can control which services to load.

- Baloo can be completely disabled by disabling file search.

- Akonadi is just "Online accounts". Add nothing, it consumes nothing.

- KRunner runs on plugins. You can disable any and every plugin, which will reduce its memory footprint too.

- You can uninstall any KDE feature package (at least in Debian), and these features will magically disappear from KDE interfaces.

Lastly, as another user noted, KDE and Qt has a self-resizing magic, and will try to minimize its memory footprint when the system has low memory. So, you can run KDE on a 4GB system and a 32GB system. KDE will allocate more in the second system, but will evict as much as possible as the memory load increases. Witnessed this in a professional project where we ran KDE on extremely limited thin clients and saw how it behaves.

> You can uninstall any KDE feature package (at least in Debian), and these features will magically disappear from KDE interfaces.

You didn't actually try this. It makes me annoyed that you think you can go on the internet and just claim something and expect it not be verified; what a bunch of nonsense.

In Debian 11.5, when one tries to uninstall any of kactivitymanagerd, polkit-kde, kaccess, then the package manager also takes out KDE as a whole.

There are core and optional components of KDE. kactivitymanagerd is a core component, so it reverse-depends plasma, that's true.

> You didn't actually try this.

No. I tried this and did more. Like using Debian for 15 years, KDE since 3.5.x days or leading a Debian derivative distro's development for 5 years, and deploying that derivative nation-wide from thin-clients to heavy metal.

> It makes me annoyed that you think you can go on the internet and just claim something and expect it not be verified; what a bunch of nonsense.

Same here.

Let's not project our prejudices to others unchecked, OK?

If you want to verify my claims, my webpage is there, with links to anything and everything I do.

The fact that you need to bet is exactly the problem, even when you are right. The article does 'blind monitoring of memory usage', which the comment you respond to points out suggest to the problematic, but in fact could also be benign and even beneficial.

So consider you are right and memory usage after boot correlates to being less snappy. That might be just a coincidence, with N being so small, and not a cause. Or maybe there is an interesting, unmentioned cause for both.

Or maybe the higher memory usage is due to features that most users actually want, for example better file indexing for search or whatever. It is not surprising to me that offering less features result in faster systems. In this case the comparison doesn't really make sense.

But it would also not surprise me if a system that uses a lot of memory is faster, if it uses that memory for caching for example.

So we don't know what 'free memory after boot' is a signal of and we don't really know if that is even important. Maybe it is to some who have 4gb or less memory. I have 64gb in my laptop, why should I care? (honest question, I can think of reasons).

If you are going to measure a signal, it is only going to be useful if you have a sound story about what the signal represents and why we should care about it. Otherwise its just a blind ranking game, kind of an e-sports competition, which will perversely incentivize useless investments (of time) and choices.

>I bet smaller memory use and snappiness correlate

You bet, but do you have any experience of any kind to back this up or is it just a vague hunch?

In my anecdotal experience, the snappiness of a DE is given almost exclusively by the compositor and amount of CPU cycles and disk I/O ops used by the DE, and less about the RAM used. Of major importance is the input lag of the compositor, with Wayland feeling far more snappier than X11 in most cases.

So I wish more of these tests would investigate CPU usage and disk I/O, rather than these RAM tests where users come to the premature "oh look, DE_1 at idle uses 200MB less RAM than DE_2, so it must be faster" conclusion, which couldn't be more false in the real world usage scenarios of how human users perceive snappiness. There's much more to this than just idle RAM usage.

So to contradict you, no, idle RAM usage does not in any way always directly correlate to perceived DE snappiness.

Why not try to measure snappiness directly? There's tons of research about this in UX land, which is not my field but I'm aware of it, defining precisely which kind of interactions at what latencies feel instantaneous and so an and so forth.

There is a lot of focus on measuring the system in linux land (cpu, memory, io, etc) from the perspective of a user (and by users), but its actually often the least informative. Developers and operators often benefit more from this level of measurement.

I suspect this is because its much easier to measure system utilization in a standardized way. Maybe this is a nice project to develop user friendly and standardized application level benchmarking for linux desktop (these are more readily available in web development).

'... I bet smaller memory use and snappiness correlate ...'

one way to probably look at this is as follows: optimising on memory usage f.e. by packing/encoding more information in a limited space, results in reduction of running time of programs. this is because, you reduce the amount of 'stuff' that needs to be moved around in memory (and programs are always doing that).

I run both XFCE and Gnome, and XFCE is much snappier.

Gnome does a lot more, and is a lot easier to extend given the JS support, but that has an impact on resource usage.

Hmm. I can see how my argument came across as anti-correlation. But, my intent was to highlight how unreliable “memory used” is as a metric for how good&usable a desktop environment is. Not doubting whether xfce could be snappier than KDE while using less resources. It could also be doing far less right?

> But, my intent was to highlight how unreliable “memory used” is as a metric for how good&usable a desktop environment is.

I don't think this is what TFA is about at all. It is merely comparing resource usage, I don't see it making any other statements. This is useful if you must decide what to use on a less powerful PC.

Yeah, but Xfce also has fewer features and less polish. e.g. I have had regular problems with connecting multiple monitors or from restarting a monitor etc. KDE also on the other hand has more useful applications pre-loaded (for minimalists it might be "bloat") but like others said, if you have the disk and memory why not get a more useable DE.

Not used KDE for ages, but personally I find XFCE and Cinnamon more usable than the Gnome desktops. But then I am pretty old school.

That used to be true, but since KDE4 hit the scene, KDE is typically just as snappy. That's probably not true for low low memory situations, but in general that's been my experience.

And my primary desktop is i3, if that tells you anything. OTOH, even when running KDE I tend to use small tools such as leafpad, konsole, vim, etc.

Reply on news.ycombinator.com