Bug 489150 - Klipper is causing plasmashell process to consume more RAM than it should for any given set of clipboard history
Summary: Klipper is causing plasmashell process to consume more RAM than it should for...
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Clipboard widget & pop-up (show other bugs)
Version: 6.1.0
Platform: Manjaro Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-25 00:16 UTC by medin
Modified: 2024-07-10 20:04 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
High CPU usage (512.06 KB, video/x-matroska)
2024-06-25 07:26 UTC, medin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description medin 2024-06-25 00:16:49 UTC
I set my Klipper history to 700 entries to use as backup for my previous copied items between sessions.

I checked the size of "~/.local/share/klipper/history2.lst" and was only about 24.3MB.

But after each login plasmashell process consumes more than 700MB of RAM.

If I disable Klipper in System Tray settings then restart plasmashell, its RAM usage drop to <300MB.

It seems like plasmashell is loading all of saved entries inside a non optimized data structure.


Operating System: Manjaro Linux 
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.6-1-MANJARO (64-bit)
Graphics Platform: Wayland
Comment 1 medin 2024-06-25 07:26:54 UTC
Created attachment 170946 [details]
High CPU usage

It also causes high CPU usage when a screenshot is taken.
Comment 2 Nate Graham 2024-06-25 15:10:11 UTC
Is the history full of screenshots? Yes, when they're in the history they get loaded into memory.
Comment 3 medin 2024-06-25 15:35:18 UTC
(In reply to Nate Graham from comment #2)
> Is the history full of screenshots? Yes, when they're in the history they
> get loaded into memory.

It will surely contain everything I copy and paste, including taken screenshots.

But I always delete old screenshots from "~/Pictures/Screenshots", and its current size is only 15MB.

So it's not logical if 24.3MB of text plus 15MB of screenshots will take 500MB of RAM. The projection of items saved on disk to RAM is simply not done correctly.

The problem will be serious for people with bigger history like 2048, the way how Klipper loads its full history is not optimal, instead it could load a limited number of items, and have "more" button at the end for more loading at demand or as the user scroll to end.

And even if the loaded items will be limited, the textual search should be optimized to cover the whole history by using an index.
Comment 4 Nate Graham 2024-06-26 19:08:37 UTC
Screenshots are referenced by path, not encoded as binary data into the history file. So f your history includes links to 10 screenshots and each is 5 MB, the memory usage will logically grow by 50 MB, but the history file won't get much bigger.

So how many screenshots are in your history?
Comment 5 medin 2024-06-26 22:28:50 UTC
(In reply to Nate Graham from comment #4)

> So how many screenshots are in your history?
 
Currently, the folder "~/Pictures/Screenshots" with a size of 16.5MB has about 121 screenshots, all of them were added by Spectacle to Klipper, the biggest one has a size <1MB.

I don't know how to count the whole number of screenshots (present+deleted) in my 700 history. Because some old screenshots were already deleted using Dolphin.
Comment 6 Nate Graham 2024-06-27 15:15:28 UTC
Ok yeah, that's definitely not enough content to reasonably cause that much memory usage, even if all the images are stored in memory uncompressed.

I can reproduce the issue. For example I copied the image data in Gwenview for an image that's about 1 MB in size, and plasmashell immediately rose in memory usage by 4 MB.
Comment 7 medin 2024-06-27 17:58:44 UTC
Thanks for debugging the problem, just a small question, why does Klipper needs to load all the previous copied images into memory? 

If an image is referenced by a path, then it just needs a small preview to be drawn inside Klipper interface as en entry instead of holding the whole picture in memory.

The only picture that should be fully loaded into memory should be the currently selected/copied.
Comment 8 Nate Graham 2024-07-10 20:04:25 UTC
It's a good question. There's probably some optimization we can do here.