Copyq: High cpu in gnome-shell when interacting with copyq

Created on 10 Jan 2020  路  11Comments  路  Source: hluk/CopyQ

CopyQ Clipboard Manager v3.9.3
Qt: 5.11.3
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Ubuntu 19.10

I've noticed my os becomes really slow when copy pasting. By using top command I see that it is gnome-shell spiking the cpu to 100% for no apparent reason. I saw this is also happening when clicking the copyq taskbar icon (taking many seconds to appear, spiking gnome-shell again).

Disabling copyq makes everything fast again. (I have two screens so might be related to #1286).

bug

Most helpful comment

Getting data from clipboard is non-blocking in the clipboard monitor process in CopyQ. This means that if a data change is detected again while still fetching previous data from clipboard there will be multiple requests to get the data.

From the timestamps in the logs it looks like exactly that is happening.

I'm fixing this so that the clipboard monitor requests the data from clipboard/selection only after any previous request finishes.

All 11 comments

Why does it say "Qt: 5.11.3"? Ubuntu 19.10 contains Qt 5.12.4. How did you install CopyQ?

I don't remember exactly. Reinstalled according to the instructions on github. Will reopen if it's slow again.

I'm not the OP but I have the same issue, i.e., copyq performs well after starting up, but after a while (30 minutes or so) copy and paste comes to a complete crawl.

I'm talking about a delay of around 1 - 2 seconds on simply doing a copy and paste operation in, e.g., Sublime Text 3. As soon as I quite copyq the system is fast again.

I do have two screens, i.e., an external monitor connected to my laptop, but for me, the issue occurs independently of the external monitor.

CopyQ Clipboard Manager v3.9.3
Qt: 5.12.4
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Pop!_OS 19.10

For me the reinstall seems to have done the trick (so far...).

For me the reinstall seems to have done the trick (so far...).

Ok, completely removed CopyQ and re-installed it. I'll report back how it performs now.

For me the reinstall seems to have done the trick (so far...).

Ok, completely removed CopyQ and re-installed it. I'll report back how it performs now.

Reinstalling helped somehow. There is still a "lag" but not as much as before which makes it possible to work with having CopyQ running all the time again.

I had the lag today as well, so reopening.

What does copyq --version say now (after the reinstall)?

Is there any error or warning in the logs (F12 shortcut from main window)?

What does copyq --version say now (after the reinstall)?

Is there any error or warning in the logs (F12 shortcut from main window)?

Still the same as before:

CopyQ Clipboard Manager v3.9.3
Qt: 5.12.4
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Pop!_OS 19.10

The logs don't have any major errors in there (at least not what I can see). However, I see lines like the below all over:

Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: ELAPSED 12169 ms acessing "UTF8:image/gif"
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: ELAPSED 12600 ms acessing "UTF8:image/gif"
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: ELAPSED 12846 ms acessing "UTF8:image/gif"
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: ELAPSED 13151 ms acessing "UTF8:image/gif"
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.965] <monitorClipboard-10519>: ELAPSED 13413 ms acessing "UTF8:image/gif"
Warning [2020-01-10 12:58:05.966] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.966] <monitorClipboard-10519>: ELAPSED 13688 ms acessing "UTF8:image/gif"
Warning [2020-01-10 12:58:05.966] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.966] <monitorClipboard-10519>: ELAPSED 13959 ms acessing "UTF8:image/gif"
Warning [2020-01-10 12:58:05.966] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.966] <monitorClipboard-10519>: ELAPSED 14182 ms acessing "UTF8:image/gif"
Warning [2020-01-10 12:58:05.966] <monitorClipboard-10519>: Clipboard data expired, refusing to access old data
Warning [2020-01-10 12:58:05.966] <monitorClipboard-10519>: ELAPSED 14474 ms acessing "UTF8:image/gif"

Maybe the lag comes from CopyQ trying to find data and if this is a sync event it will block during that time? (Just a guess as a fellow developer) :)

Getting data from clipboard is non-blocking in the clipboard monitor process in CopyQ. This means that if a data change is detected again while still fetching previous data from clipboard there will be multiple requests to get the data.

From the timestamps in the logs it looks like exactly that is happening.

I'm fixing this so that the clipboard monitor requests the data from clipboard/selection only after any previous request finishes.

If you want me to test anything, please let me know.

Was this page helpful?
0 / 5 - 0 ratings