KDE SC 4.7 Release Candidate Hits The Web

[priomsrb]

Now that KDE developers have run out of "new great features" to add, maybe they'll start thinking about overall KDE optimization (KDE4 RAM consumption is just insane) and bug fixing?

I did some RAM measurements on my Arch laptop recently.

When I start up my KDE session I use up about 130MB of RAM. This is with plasma and desktop effects running. I turn off stuff I don't need like nepomuk.

With a web browser (rekonq), file manager (dolphin), terminal (konsole), text editor (kate) and pdf reader (okular), I measured my RAM usage to be less than 200MB.

Proof: Clean start, after opening apps

[RealNC]

KDE4 basic desktop with no applications/no plasmoids running consumes on average up to 500MB of RAM.

If you don't believe me, run the following experiment:

1) log off from your KDE session
2) switch to a text console, login as root, run `echo 3 > /proc/sys/vm/drop_caches`, then `free`. Remember how much RAM is actually free.
3) switch back to you graphical login manager, log in as a user, wait for KDE session to complete loading.
4) switch back to the text console and run `free` again.

Now you can compute how much RAM your KDE session really eats. And that number will astonish you, I promise

I get 206MB usage doing that. I'm running KDE 4.6.4 on Gentoo Linux.

Edit: Actually, that's 206MB *total* usage. If I try to compute what KDE is using, I get something like 150MB.

[Jimbo]

Sometime ago, I filled a bug about akonadi / nepomuk *brutal* memory usage on kde, of course I obtained no response (well, I was expecting that). If you are concerned about kde memory usage , you could vote this bug:

https://bugs.kde.org/show_bug.cgi?id=262981

As birdie has already pointed , opening a mysql instance to waste 200 - 300 MB of memory is just not the best idea to implement on a DE.

[RealNC]

Sometime ago, I filled a bug about akonadi / nepomuk *brutal* memory usage on kde, of course I obtained no response (well, I was expecting that). If you are concerned about kde memory usage , you could vote this bug:

https://bugs.kde.org/show_bug.cgi?id=262981

As birdie has already pointed , opening a mysql instance to waste 200 - 300 MB of memory is just not the best idea to implement on a DE.

If you're using the normal MySQL backend, then that's what you should expect. The embedded MySQL backend doesn't need that much memory.

http://techbase.kde.org/Projects/PIM...abase#Backends

[Jimbo]

I was using the default. Thx for the info. Anyway, from the info you provided there seems to be problems with other backend. I guess Sqlite should be the default once the remaining problems are solved.

*MySQL*

Status: working, default backend for desktop systems

*Sqlite*

Status: working with limitations, default backend for mobile systems

Supported modes: Embedded

Known issues:

Requires newer version than the default Qt one.
Requires patched QtSql driver to fix concurrency issues

*PostgreSQL*

Status: unknown

*Virtuoso*

Status: not working

*MySQL/Embedded*

Status: not working

[kraftman]

Boy, that's the total opposite of my experience. I started using Arch with KDE with version 4.5 and by the time it got to 4.6.3 the bugs were so many I couldn't properly use my system anymore without loosing some time after boot putting everything "alright" again. Not to mention that I'm constantly switching between my laptop's internal screen and an external monitor and that causes huge amounts of failures on KDE due to its pathetic multi-monitor support. Seriously, they should start listening to their users more (by ways of the bugtracker's wishlists and bug reports) and stop making up new K3wl features :P

I can imagine your pain, but it's not the same for every user. I'm using desktop PC and I rarely have problems with Linux and KDE on it. I'm free of most of the bugs probably. The hardware and drivers makes a difference and it's not always DE fault. In example I hit some bugs on Windows like mouse sometimes being blocked in FPS games. It blocks only when I move mouse to the left. Nothing like this I've ever had on Linux. Another example is I had some stability problems with Gnome2 and Fedora. Sometimes it's probably good to check what hardware devs are using.

[kraftman]

KDE4 basic desktop with no applications/no plasmoids running consumes on average up to 500MB of RAM.

If you don't believe me, run the following experiment:

1) log off from your KDE session
2) switch to a text console, login as root, run `echo 3 > /proc/sys/vm/drop_caches`, then `free`. Remember how much RAM is actually free.
3) switch back to you graphical login manager, log in as a user, wait for KDE session to complete loading.
4) switch back to the text console and run `free` again.

Now you can compute how much RAM your KDE session really eats. And that number will astonish you, I promise

I think the proper way to measure RAM usage on Linux is to check system monitor. It uses more advanced algorithm than free. KDE also uses cache.

[kraftman]

A dozen instances of the same process won't eat that much RAM since all of the code and library and read-only data segments are shared. Take a look at /proc/<PID>/smaps for one of those and see how memory is actually private and resident in memory.

Maybe you're right, but the system monitor counts them like different processes. I don't have Kubuntu installed right now, but it will be nice to check this.

[kraftman]

And when KDE4 is finally as stable and mature as 3.5 was the devs *must* scrap it all and go back to the drawing board again for KDE5 just because...

Thankfully they won't do this.

[siride]

I think the proper way to measure RAM usage on Linux is to check system monitor. It uses more advanced algorithm than free. KDE also uses cache.

free is actually your best bet. System monitor can't be smarter than free because free is as smart as it could be possibly be, at least for this simple case.