Fix 100% CPU on startup with large clipboard history

[EricBlanquer]

Problem

On Ubuntu Noble (24.04) / Linux Mint 22.3 with Cinnamon, Diodon 1.13.0 consumes 100% CPU immediately on startup when the Zeitgeist clipboard history contains many items (30+), especially large text items or images. The process never becomes idle.

GDB backtrace shows the main thread stuck in:

#0  pcre2_match_8()                       libpcre2-8.so.0
#1  g_match_info_next()                   libglib-2.0.so.0
#2  g_regex_replace_eval()                libglib-2.0.so.0
#3  g_regex_replace_literal()             libglib-2.0.so.0
#4  string_replace()                      libdiodon.so.0
#5  diodon_clipboard_menu_item_construct()
#6  diodon_clipboard_menu_append_clipboard_item()
#7  diodon_clipboard_menu_construct()

Root cause

Two performance issues compound into a CPU spin:

1. TextClipboardItem.get_label() processes entire text before truncating

_text.replace("\n", " ") compiles (via Vala) to g_regex_replace_literal(), which runs the entire string through PCRE2. For large clipboard items (found a 74KB text item), this is extremely wasteful since only 50 characters are displayed.

2. ImageClipboardItem.with_payload() fully decodes PNG on construction

Every image is decoded from PNG into a Gdk.Pixbuf immediately when loaded from Zeitgeist. With 50 recent items including multiple 100KB–1MB PNG screenshots, this decodes tens of MB of PNG data on every menu rebuild.

Fix

Text items: Truncate the string early (200 bytes max) before processing, and use split()/joinv() instead of regex-based replace().

Image items: Defer Gdk.Pixbuf decoding until the pixbuf is actually needed (paste, icon display). Keep only the raw payload in memory after extracting dimensions and checksum.

Testing

• Verified on Linux Mint 22.3 / Cinnamon 6.6.7 / X11 / GLib 2.80.0
• meson setup build && ninja -C build compiles without errors
• Before fix: 100% CPU with 30+ items in history
• After fix (clean DB + fix applied): 0% CPU with 37+ items

Workaround (without this fix)

killall diodon zeitgeist-daemon
rm -f ~/.local/share/zeitgeist/activity.sqlite*
rm -rf ~/.local/share/zeitgeist/fts.index
zeitgeist-daemon --replace &
diodon &

[sliverc]

Thanks for your contribution. Can you send me the prompts you used to generate this PR? that would be very helpful.

[EricBlanquer]

Hi @sliverc

Me:

Last week or before, I don't remember exactly, we installed copyq to replace diodon because it stopped working, but I really don't like copyq which works poorly compared to diodon. Remove copyq and either figure out why diodon doesn't work here when it works on another of my machines.

Claude response:

I'll first check the current state of CopyQ and Diodon on this machine.
[Checked system, found CopyQ running, Diodon not installed]
OK, clear situation: CopyQ is installed and running, Diodon is not installed but available in repos. Cinnamon 6.6.7 on X11.
Let's first try to install Diodon and get it working, before removing CopyQ.
[Installed Diodon, launched it]
Diodon installed. Let's try launching it to see if it works.
[Found Diodon spinning at 100% CPU]
Problem identified: Diodon consumes 91% CPU. It's a known bug. Let me investigate.
[Used GDB backtrace, found the issue]
Found the problem! Diodon is stuck in a catastrophic regex (pcre2_match_8 → g_regex_replace_literal) during clipboard menu construction. A clipboard history item is causing infinite backtracking in the regex engine.
The solution: clear the Diodon history.
[Cleared Zeitgeist database history]
Still 100% CPU even with empty history! The bug is in the Diodon code itself, not the data.
[Further investigation, tested with different item counts]
The problem appears between 20 and 30 items. There's a specific item causing the block. Let me identify it.
[Analyzed the issue more deeply]
With recent-items-size=0, Diodon runs at 0% CPU! The problem is loading recent items.
[Tested incrementally: 5, 10, 20, 30, 40, 50 items]
The problem appears between 20 and 30 items.
[Decided to nuke and rebuild Zeitgeist DB]
The user is asking to clear the history. Let's do this properly.
[Backed up and deleted Zeitgeist DB (297MB freed), restarted clean]
Diodon runs at 0% CPU with empty history! Let's test functionality.
[Tested clipboard capture, stress-tested with 30 items]
Perfect, 37 items and 0% CPU. Now let's remove CopyQ.
[Removed CopyQ, added Diodon to autostart]
Done. CopyQ removed, Diodon working at 0% CPU with autostart configured.

Me:

Can you propose a fix to the community?

Claude response:

Good idea. Let me first understand the code to patch properly, then prepare the issue and fix.
[Analyzed Vala source code, identified two root causes]
Root cause identified:

    TextClipboardItem.get_label() processes the ENTIRE text through PCRE2 regex (via string.replace(" ", " ")) before truncating to 50 characters. For a 74KB text item, this is extremely wasteful.
    ImageClipboardItem.with_payload() fully decodes each PNG into a Gdk.Pixbuf immediately on construction. With 50 items including multiple 100KB-1MB images, this decodes tens of MB of PNG data on every menu rebuild.

[Attempted to create GitHub issue - issues disabled]
Issues are disabled on GitHub. Let me check if they accept PRs.
[Found PRs are accepted, forked repo, created fix branch]
The project accepts PRs! I'll create a PR with the fix.
[Implemented fixes for both issues, tested compilation]
Fix 1 (text): Truncate to 200 bytes before processing, use split()/joinv() instead of regex-based replace()
Fix 2 (images): Lazy pixbuf loading - extract dimensions/checksum at construction, but defer full PNG decode until actually needed
Compilation OK.

[sliverc]

Thanks a lot. This is very helpful. In Diodon did you activate "add images to clipboard histroy' setting? Do you remember? By default it is turned off.

[EricBlanquer]

yes @sliverc
I've enabled "image to clipboard", very useful for me

[sliverc]

OK most likely images are causing the problem.

Question: You wrote in the prompt that "diodon stopped working". What did you noticed that it stopped working? It would not start at all or taking a long time? Or was their another problem when opening the menu...?

[EricBlanquer]

Diodon was running in the background but completely unresponsive. The keyboard shortcut (Super+V) would not open the menu at all. Command-line verification showed the diodon process was consuming 100% CPU permanently (not just temporarily during startup).

[sliverc]

Thanks. I assume copying of a large image caused this. For now I recommend you disable adding images to clipboard history and I will look into it to see how to improve it.