Steve Litt - 10.07.24, 18:42:59 CEST:
> dbus. Also, it's got so much stuff interacting with each other that
> it's a resource hog, and if your computer is at all flaky, KDE will
> make it flake much more often. Imagine you've opened Chromium tabs for
> Javacript piggy sites Buick.Com, Ford.Com, Chevy.Com, Jeep.Com and
> Dodge.Com. In the best of situations your computer will be slow and
> maybe glitchy. Now throw in the KDE resource hog, and watch your
> problems multiply.

That KDE is a resource hog is a myth.

Especially regarding memory usage they added a very detailed memory usage
analysis to the process monitor, cause at one point they were fed up with
people comparing memory usage of processes who do not understand a thing
on how to *accurately* determine that value to begin with – even going as
far as using VIRT / VSZ value which is complete madness. The feature they
added to the process monitor clearly shows which memory is really unique
to the process, which memory is from libraries and thus shared with other
processes. It then shows the Proportional Set Size (PSS) which is memory
unique to the process plus memory shared with others divided by the count
of all processes using it. And of course its real memory and not virtual
address space they account for.

There are parts of KDE Plasma and KDE Gear – they name a big collection of
applications like this these days – that can be quite resource hungry and
even a resource hog. But hey if you add applications to the mix, even a
fvwm2 based desktop can be heavy!

This is Baloo, the desktop search. If you tell it to index file contents it
can be quite resource heavy. Especially older versions that for example
thought often enough that files on BTRFS are all new again, indexing them
another time and probably then other and so on. But this has been fixed,
among with a lot of either bugs. For my private machine I still only let
it index filenames which is barely noticeable. My company laptop indexes
everything. I have much less data there and its not a problem anymore.

Then there is Akonadi and frankly, so far I am concerned it is indeed
quite broken and has been that way since quite a while. I still stick with
it, cause I love KMail so much and I have such a complex mail setup… sure
I can migrate, but I was waiting for improvements so far, maybe too long,
I know. It is the foundation for the PIM applications. The idea is sound,
but the implementation lacks on reliability and indeed currently can be a
heavy to very heavy resource hog. Ideas are there how to fix it, and they
now even have a road map. And I am really looking forward to their "making
indexing great again" and their switch to SQlite3 instead of full blown
MariaDB or PostgreSQL database. Actually with my 1-2 million of mails
stored via Akonadi I have chmod 000 akonadi_indexing_agent, cause
currently it is no fun to have it run, even on this powerful machine. I am
looking forward to have indexing fixed, cause being able to full text
search mails with an always up to date index would be awesome.

Also most of this resource hogging is disk I/O related. Neither Akonadi
nor Baloo could even remotely use all of the CPU cores of a not too old
laptop.

But… if you

1. let Baloo to just index filenames, not contents, at least if you have
many and many heavy, text heavy files, have a crazy amount of files that is,

2. remove MariaDB and PostgreSQL Akonadi backend and only have SQLite 3
backend and use either Thunderbird or Evolution – which is a really nice
GNOME app – or some other mail client¹,

3. only install the stuff you need or remove what you do not need,

then KDE Plasma is no resource hog. Of course if you load a 10000x10000
image into Krita for example… no surprise it will use some resources.

-----------------------------------------------------------------------

[1] which means Akonadi holds almost no data and does that within an
SQLite3 database, which means Akonadi does not use many resources, if at
all. You can also stop it, but it could be started automatically again. I
think with SQLite3 they use it even in Plasma mobile, so if you do not
stuff a million mails into it and use it only with a smaller dataset, it
probably could even be fine. But if you to access a lot mails fast and you
do not mind using a console client, probably and likely notmuch would be
more in your favor, cause it really is not much mail. I did not test it so
far, but I expect it to fly circles around Akonadi with large datasets.

-----------------------------------------------------------------------

Especially an idle KDE Plasma basically does just that then: Idling.
Meaning for example 0-3% of 1600% CPU on this AMD Ryzen 7 8840U, including
Atop displaying metrics and Akonadi even running in the background with a
complete PostgreSQL database – totaling 8 cores with hyper threading, thus
is could go to 1600% of CPU usage, but it would never do this… not even
with Akonadi indexing running mad. Sure its a very powerful CPU, but even
on the Gen 1 with its older AMD Ryzen CPU it was not really different. Even
with ThinkPad firmware which tends to up the fan quite proactively often
enough the fan is 0 RPM and almost all the time with an almost idle
session – including crazy Akonadi setup – less than 2000 RPM and thus
barely noticeable almost *all of the time*. Heck I even installed a
minimal KDE Plasma laptop with Thunderbird and Akonadi silenced with
SQLite3 and almost no data in it on an old Fujitsu laptop with 4 or 6 GiB
of RAM and… very old CPU. Its absolutely no problem. Not even with Signal
running as a heavy Flatpak application.

About complexity I agree Steve. KDE can be and is quite complex – as any
other integrated desktop environment on Linux to some extent, even LXqt,
which is indeed using KDE Framework libraries for many things. And yes,
LXDE and LXQt are more lightweight, but you have the complexity regarding
DBUS and PolicyKit as well. If you like to avoid that it is basically
doing it the good old way, have a WM like awesome or whatever and some
little desktop apps. If that is fine with you, sure go ahead. We have
choice within Linux for a reason! And yes, would it be more lightweight?
Sure it would!

But I love the integrated feel of Plasma desktop, the use of their
Activities feature which is one of the best, but unfortunately somewhat
hidden ideas I have ever seen in a desktop environment, and quite some of
the really excellent KDE applications which meanwhile often surpass
extremely expensive applications for Windows.

Also KDE is one of the few projects even looking into resource usage of
their apps from a ecological point of view with the KDE eco project. Their
PDF viewer Okular meanwhile has the German "Umweltzeichen Blauer Engel"
(blue angel) certification.

Steve, especially it is funny as you talk about resource hog and
complexity and then mention Chromium and JavaScript. Web browsers with
crazy JavaScript and image or video heavy sites… complex they are. A
resource hog they can easily be. Javascript in web browsers is often
enough basically re-introducing proprietary closed source software through
a backdoor. An idle Plasma desktop would not really add much or rather
take much away from the raw performance you can have for Chromium.

I really vote for more discernment instead of globally saying: KDE is a
resource hog. It is not. At least not by any standard using it on even a
10 year old or probably older machine. Would I use it with 2 GiB of RAM?
No. I bet it would work fine enough in a minimal setup, but I would not do
that. Actually I did. Long enough. On a ThinkPad T42 with laptop hard disk
– the bottleneck was easily the hard disk. I think that old ThinkPad T23 I
used once even had less than that, probably 768 MiB. It still worked with
the older KDE back then. And the main resource hog on that machine was
locate updating its locate database with a 2.5 laptop hard disk drive.
This basically crawled the machine to a halt.

--
Martin