KDE Plasma 5.9 Being Released In One Month With Many New Features

[useless]

birdie

As far as I know there are no tools for Linux which can conclusively/exactly calculate RSS usage so 90MB of shared RAM is a figment of your imagination.

RSS it's at most an overestimation of the memory owned by a process. ksysguard reports PSS memory, which is a better estimation of process used memory. My PC (1 week uptime) throws a private memory of 176 MiB and a shared of another 100 MiB for plasma-shell (full blown desktop with lots of plasmoids, open apps, etc), which divided by the number of processes using it gives only 14 MiB. So the numbers we are saying (~400 MiB for a fresh start) are reasonable.

When I ran my copy of the KDE Neon image I had nothing in tmpfs. Also could you please tell me how the kernel could have used 350MB of RAM?

By the image you posted it's a livecd image, right? Doesn't the squashfs set an overlay tmpfs? oh yes, it does!

Also, seeing that I totally dropped caches, do you really believe that memory could have been used by anything else? Hell fucking no! It's 100% claimed and 100% allocated.

Didn't I posted that dirty pages in cached mem can't be claimed by only writing to drop_caches? It's on the man page for god sake. And for the last time: cached mem are a CACHE for files (or any other block device). It's NOT memory allocated to any user process.

It seems like every idiot on Phoronix can claim whatever BS they imagine about their $favourite_de yet I'm the only one who can stand for his claims using hard numbers.

Your hard numbers are based on incorrect assumptions of how linux memory management works.

PS: Plasma desktop can be improved? Sure! Does it work nicely enough tough? For me, and a lot of people, yeah!

[devsk]

200MB - 90MB = 115,343,360 bytes (922,746,880 bits)

This says a lot about the memory efficiency of algorithms employed by the software.

Yeah, agreed. That's engineers lazy enjoying hardware leaps...:-) But we are talking relative terms. I don't see KDE being any more memory inefficient than any other big open source project. Recent releases of framework, apps and plasma have improved in this area quite a bit compared to like 6 months ago.

[devsk]

It seems like every idiot on Phoronix can claim whatever BS they imagine

Seems like you are talking about yourself...:-)

I knew you were a famous troll but to this extent...I am appalled! I salute you for the troll king you are and give up!

[schmidtbag]

birdie
Had it not occurred to you that maybe, just maybe, if everyone disagrees that you are the one who is wrong or stupid? You claim you want hard numbers yet everything you're commenting is anecdotal. For a piece of software used by thousands of people, anecdotes are statistically irrelevant.

Sure, there are situations where everyone but one person is wrong because everyone fails to see the truth or chooses to ignore it. But you are crudely arguing against statistical averages.

This is not the first time people got fed up with your antagonizing rants. Why do you expect anything different? Do you even post bug reports?

If you hate KDE5, fine - nobody is stopping you from using it.

[birdie]

Obviously, you did not account for SHM part of the process memory usage. I don't think you know what you are talking about...:-) Your data shows only 350MB being used. The kernel has used the other half of 700MB for whatever purposes e.g. may be a tmpfs, which will not be freed by drop_caches or memory explicitly locked by some kernel threads/daemons or slab memory which is unevictable. You can't blame KDE for that 350MB. It goes to show you just hate changes in KDE since 3.5 and looking for excuses to fit that narrative.

On my system, plasmashell uses 200MB with 90MB of it shared with other KDE processes after 5 days of uptime and fully loaded desktop.

As far as I know there are no tools for Linux which can conclusively/exactly calculate RSS usage so 90MB of shared RAM is a figment of your imagination.

Also why everyone who disagrees with me here in Phoronix is so full of shit? Go download the same KDE image which I used for testing and show a single byte allocated for tmpfs. Don't tell me you cannot, or that you have no time, cause clearly you had more than enough time to write a reply.

When I ran my copy of the KDE Neon image I had nothing in tmpfs. Also could you please tell me how the kernel could have used 350MB of RAM? Also, seeing that I totally dropped caches, do you really believe that memory could have been used by anything else? Hell fucking no! It's 100% claimed and 100% allocated. I was not talking about VIRT memory usage for fuck's sake. I was talking exactly about RES (ident memory), and you just cannot do anything about that RAM unless you swap it out which means your swap partition gets used and that's a whole different issue I wasn't even talking about.

If you think KDE Neon is not the best example, then please, boot into your super optimized Linux distro with KDE5, run Konsole, run `sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"` in it and show your `free` output. Then we'll talk.

It seems like every idiot on Phoronix can claim whatever BS they imagine about their $favourite_de yet I'm the only one who can stand for his claims using hard numbers.

[atomsymbol]

Obviously, you did not account for SHM part of the process memory usage. I don't think you know what you are talking about...:-) Your data shows only 350MB being used. The kernel has used the other half of 700MB for whatever purposes e.g. may be a tmpfs, which will not be freed by drop_caches or memory explicitly locked by some kernel threads/daemons or slab memory which is unevictable. You can't blame KDE for that 350MB. It goes to show you just hate changes in KDE since 3.5 and looking for excuses to fit that narrative.

On my system, plasmashell uses 200MB with 90MB of it shared with other KDE processes after 5 days of uptime and fully loaded desktop.

200MB - 90MB = 115,343,360 bytes (922,746,880 bits)

This says a lot about the memory efficiency of algorithms employed by the software.

[devsk]

Buffers totally flushed, no applications running at all (only konsole), 700MB memory usage on fresh start. "200MB", my arse.

Let's break it up by processes:

Plasmashell - 177MB
Krunner - 130MB
kwin_x11 - 109MB
...

Obviously, you did not account for SHM part of the process memory usage. I don't think you know what you are talking about...:-) Your data shows only 350MB being used. The kernel has used the other half of 700MB for whatever purposes e.g. may be a tmpfs, which will not be freed by drop_caches or memory explicitly locked by some kernel threads/daemons or slab memory which is unevictable. You can't blame KDE for that 350MB. It goes to show you just hate changes in KDE since 3.5 and looking for excuses to fit that narrative.

On my system, plasmashell uses 200MB with 90MB of it shared with other KDE processes after 5 days of uptime and fully loaded desktop.

[Luke_Wolf]

- In my opinion, an issue with C/C++ is the absence of source code validation tools from the programming process.

What precisely do you mean by validation in this case? C and C++ have unit test systems, they have static analyzers, fuzzers, and things to check valid memory usage like Valgrind. It's true that Rust and C# or whatever have a higher level of introspection into the code, but that's not quite the same thing as validation.

- Pet languages: Using a pet language is OK if there exists a succinct universal bidirectional interface between C/C++ and the pet language. It is a matter of how easily and efficiently the pet language can talk to the already existing language(s). Swig is too cumbersome.

What exactly is it that you want? You're complaining about C and C++ without providing an alternative, and in this statement despite complaining about Qt (and by consequence GTK for your complaints about C) the implication is you're married to having a C or C++ toolkit that the language is talking to... which defeats the point of complaining about C and C++

[anda_skoa]

GTK on Plasma feels half assed and out of place, especially when X app has a totally different File Chooser than Qt apps.

That sounds a bit as if the toolkit being used for these applications lack the capability to use platform native dialogs or that the respective plugin is missing.

E.g. a Qt application, which has the capability as that is part of Qt, could still be displaying a different dialog than GTK apps on GNOME if the "GTK platform theme" or "GNOME platform theme" (not sure about the actual name) plugin is not installed.

Vice versa the same will be true for a GTK application with missing "plasma" dialog plugin (or whatever kind of platform integration mechanism GTK uses).

Cheers,
_

[anda_skoa]

Hopefully plasma-shell will have a rudimentary off-main-thread UI updater - so that the panels and menus don't stop working / lockup whenever networking goes down (e.g. post-resume), etc.

I think it is the other way around.
The UI is driven by the main thread while networking, etc. is done asynchronously.

Cheers,
_