Created attachment 165095 [details] Demonstration SUMMARY In KDE you can set the clipboard history to be saved after a PC reboot and set the maximum log size to 2048 entries. However, I noticed that the clipboard keeps storing all pictures and text in RAM, which further leads to plasmashell eating 1.5 gigabytes or more from system startup. I think we should either add a warning about this in the applet settings or not load the entire clipboard history into RAM, but only a part of it and load the rest as needed. I have recorded a video demonstrating this problem. I ran a bash script that generates random text and copies it to the clipboard. You can see how the RAM consumption increases. If you reboot the PC, the RAM consumption does not decrease, only clearing the buffer and restarting the plasmashell process will help. OBSERVED RESULT The applet stores all clipboard history in RAM EXPECTED RESULT The clipboard history should be loaded in parts somehow, so as not to use too much RAM. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon Unstable, Wayland KDE Plasma Version: 6.0.80 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION I've attached a video
There is actually some performance improvements on the way, which when complete will allow images at least to not be fully stored in RAM, just the metadata and thumbnail: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2502 In theory I guess that system could even be extended to create "thumbnails" for long text stuff and just load that instead of the whole text and/or use some sort of compression, but then I wonder how common it is for people to copy long bits of text often enough for it to matter, like for reference I happen to have a document with like 120 pages of text and about 63000 words, and that's apparently about 700KB of data, so even if you had 100 such documents in text form sitting in your clipboard history that's just 70MB of data. Plus, trying to save RAM for text stuff might just slow down the search function, so it might not even be an improvement in the end. As for a warning about the RAM usage with larger history size limits, Konsole already has something similar with its scrollback limit setting (in the profile settings), so there is at least precedent for it.
(In reply to Prajna Sariputra from comment #1) > There is actually some performance improvements on the way, which when > complete will allow images at least to not be fully stored in RAM, just the > metadata and thumbnail: > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2502 > > In theory I guess that system could even be extended to create "thumbnails" > for long text stuff and just load that instead of the whole text and/or use > some sort of compression, but then I wonder how common it is for people to > copy long bits of text often enough for it to matter, like for reference I > happen to have a document with like 120 pages of text and about 63000 words, > and that's apparently about 700KB of data, so even if you had 100 such > documents in text form sitting in your clipboard history that's just 70MB of > data. Plus, trying to save RAM for text stuff might just slow down the > search function, so it might not even be an improvement in the end. > > As for a warning about the RAM usage with larger history size limits, > Konsole already has something similar with its scrollback limit setting (in > the profile settings), so there is at least precedent for it. To be honest I'm not sure if image optimization works well. Because during the week I copy a lot of images and plasmashell as I wrote starts to consume almost 1.5 gigabytes of RAM. But anyway, I think the best solution in this situation would be to just add a warning about RAM consumption, just like in Konsole.
I should have clarified that the performance improvements haven't been merged yet, so you won't see the effects of that for now.
(In reply to Prajna Sariputra from comment #3) > Я должен был уточнить, что улучшения производительности еще не были > объединены, поэтому вы пока не увидите эффекта от этого. (In reply to Prajna Sariputra from comment #3) > I should have clarified that the performance improvements haven't been > merged yet, so you won't see the effects of that for now. Oh, that was already open a year ago. I hope this gets merged eventually because images at the moment consume a lot of RAM. The end user may not even think about it and because of that the system may start to run slow where there is very little RAM.
There are definitely performance improvements possible here. However it's not as simple as "don't store history in RAM" because they you just move the problem space elsewhere by making it take a long time and wear out your disk more to access it. I see from your video that you have an enormous clipboard history. We've gotten other reports from other people who like enormous clipboard histories, and as Prajna mentions, improvements to this use case are in progress.
Mitigated in 6.3
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5000
Git commit 5e2732bb05d726efa044749dfb75ceff00cb4ee5 by Fushan Wen. Committed on 21/12/2024 at 10:31. Pushed by fusionfuture into branch 'master'. klipper: reduce memory usage when there are many images Set Image's sourceSize property to reduce memory usage. Test: Add 3 2048x2048 images, get plasmawindowed's RSS from ps command: - Before: `before: 246256 after: 389356 diff: 143100` - After: `before: 246400 after: 321944 diff: 75544` FIXED-IN: 6.3 M +7 -1 appiumtests/applets/clipboardtest.py M +1 -0 klipper/declarative/qml/ClipboardItemDelegate.qml M +4 -2 klipper/declarative/qml/ImageItemDelegate.qml M +12 -1 klipper/historymodel.cpp M +1 -0 klipper/historymodel.h https://invent.kde.org/plasma/plasma-workspace/-/commit/5e2732bb05d726efa044749dfb75ceff00cb4ee5