High CPU usage

Question

High CPU usage

Closed this issue 4 months ago · 25 comments

sentakuhm commented 4 months ago

it not always, just sometimes cpu is high

Answer 1 · 2024-04-26T10:31:27.000Z

Hi @sentakuhm 👋

Thank you for raising this. I have not seen it get anywhere near to that % before!

I will investigate this as part of the next release. To help me, could you please let me know the following:

what content type was being copied to your clipboard when the usage was showing this high? E.g image data/mp4 etc...
what is your terminal environment and OS in use? Would also be good to understand which system clipboard app you are using (xclip/wl-clipboard/something else)
did any other process spike at the same time as clipse --listen-shell or was it only this process?

Thanks!

Answer 2 · 2024-04-26T11:01:44.000Z

OS: Arch linux.
Terminal: Kitty.
WM: Hyprland.
Clipboard: wl-clipboard.

Settings on hypr:

exec-once = wl-clipboard-history -t
exec-once = clipse -listen
bind = SUPER, V, exec,  kitty --class floating -e zsh  -c 'clipse $PPID'

as i said its not always happen, but i think it happen on copying media files images/videos.
and no, no other other process spike at the same time only clipse.

Answer 3 · 2024-04-26T13:42:09.000Z

I record what happened when i take screenshot, this may help you inspecting the issue:

recording.mp4

Answer 4 · 2024-04-27T08:48:37.000Z

@sentakuhm thank you!

Looks like this is mainly gonna be down to the content type being copied (media data specifically).

I think I have a fix so gonna work on that as part of the next release. Will keep you updated 😄

Answer 5 · 2024-05-03T15:22:29.000Z

@sentakuhm I've published a new release that should have sorted this out a bit, haven't got the new Nix/Aur package sorted yet but lmk if you get this working in the meantime if it's helped at all :)

edit - what are you using to record your desktop out of interest?

Answer 6 · 2024-05-03T17:19:16.000Z

@savedra1 i'll check it out, and i use wf-recorder for desktop record.

Edit: build from source and seems worse than before, CPU usage about 67-85%.

Answer 7 · 2024-05-03T18:46:51.000Z

Thank you @sentakuhm 🙏 been looking for a good one. let me know how it goes

Answer 8 · 2024-05-05T12:22:52.000Z

@sentakuhm have just seen your edit!

Am very surprised to hear this as the change I made included significantly reducing the rate at which the app would check your clipboard contents when media data is held. The only thing I can think of that would increase the cpu usage is the updates to the UI used for this release but that should not apply here and would be super minimal.

As you built this from source, are you 100% sure the previous version is not the one that's running the listener still? Eg if you still have the previous installed, running clipse -listen maybe be using that still. I'd recommend using ./<new clipe binary> --listen shell.

The new AUR package should also be good to go now btw, maybe installing from there would help.

If it is the new version I'll need to have a deeper think about this as it's possibly caused by the way it interacts with your hyprland/shell envs.

Lmk!

Thanks 🙏

Answer 9 · 2024-05-05T13:19:58.000Z

Yes, first i completely removed the old version and build from the source, second i remove built one then installed from AUR, checking with clipse -v the output is: clipse v0.0.7 also i reboot my pc, but both gave same issue, now the issue is happen even when copy a text too.

to be sure this is my settings:

exec-once = wl-clipboard-history -t
exec-once = clipse -listen  # run listener on startup
bind = SUPER, V, exec,[float;size 450 590]  kitty --class floating -e zsh  -c 'clipse' # [float;size 450 590] is just custom window size.

Edit: do you use wl-clipboard?

Answer 10 · 2024-05-05T13:54:14.000Z

Thanks for confirming @sentakuhm. Yeah I use wl-clipboard.

I see you're also running the wl-clipboard-history script on startup, this shouldn't directly affect the behaviour of clipse but as they would both be interacting with the system clipboard simultaneously I wonder if this is causing any complications.

I would suggest stopping the wl-clipboard-history script to see if that makes any difference. Alternatively you could not run the clipse-listen and update the wrapper around wl-clipboard so that it updates the history file instead, though that would require a lot more engineering effort. Will try and replicate this myself also.

Planning to cross-compile some c for a more event-based clipboard listener, was reluctant to use an extra dependency for this wl-clipboard but may look into making that a temporary option

Answer 11 · 2024-05-05T14:27:09.000Z

2024-05-05.15-21-07.mp4

This is my htop when copying a large image file on the new release (2% CPU). What machine specs are you running? wondering if that could be making a difference also

Answer 12 · 2024-05-05T16:28:24.000Z

stopping the wl-clipboard-history script no helping.

is there any option to debug?

Answer 13 · 2024-05-05T18:29:04.000Z

I see 🤔 debugging in clipse is still limited to error messages. When clipse -listen is ran it executes the command nohup clipse --listen-shell >/dev/null 2>&1 & which discards all logs, but you could recreate this, getting it to point to a log file instead with nohup clipse --listen-shell >> /path/to/logfile.log 2>&1 & and see if that shows you anything helpful.

You could also edit the source code to add print statements if you already have an idea of what you'd be looking for here. In that case you could simply run clipse --listen-shell and see what gets printed to the terminal while the process runs.

I haven't been able to recreate this also so still wondering if it could be hardware related. Will see what debugging logs I can find though and let you know if I spot a way to find some clues.

Answer 14 · 2024-05-07T09:11:24.000Z

on log file there is no thing except nohup: ignoring input.

Answer 15 · 2024-05-07T11:22:09.000Z

Thank you for checking @sentakuhm. Looks like I would need to implement some better, system-level debugging here for that to show any info. I'm sorry we haven't got very far with this, I'm not sure of the cause still but you could try the following:

use a tool like strace/perf to inspect the PID of the running listener process. EG strace -p <PID>
clear the file contents that are being loaded into the TUI with `clipse -clear' (this will remove all clipboard histiry data and temp files used) it's possible there is a certain file that the program is having difficulty parsing
run ps aux | grep clipse to ensure only a single clipse process is running (something might be going wrong when terminating an existing listener) clipse -kill can then be used to kill all sessions
run clipse --listen-shell directly in a terminal without the nohup process to see if this helps (maybe nohup is causing some system issue)

These are the only things that come to mind for ways in which clipse is interacting with your system. If none produce any positive results will need to think about other ways to analyse what's going on under the hood when the binary runs on your system.

Your perseverance is much appriciated, let me know how it goes! 😄

Answer 16 · 2024-05-07T16:34:33.000Z

OMG!! what a relief, clipse -clear solved my issue, even after rebooting and try again cpu was only 2%. thank you!!!.

Answer 17 · 2024-05-07T17:18:43.000Z

Amazing! Must've been some unexpected binary data pattern from a certain file.

Will keep this in mind and add to the FAQs.

Thanks again for sticking with it and for using clipse 🫡

Answer 18 · 2024-06-13T13:59:31.000Z

I also get this on NixOS unstable + Hyprland... clipse eat more cpu than firefox.

Answer 19 · 2024-06-13T14:21:17.000Z

Hi @ArtemChandragupta,

Have you tried the above fix? should be due to the bin data from a certain image file causing a parse issues.

EDIT: 0.5% CPU actually sounds fairly normal, surprised at how low everything else is tbh 😆

Answer 20 · 2024-06-13T14:34:23.000Z

Is the fix is just to do clipse --clear to remove all clipboard history? Can I just remove image files by 'x' keybind?

This is not truly 0,5%, btop is weird. It actually more like 4%, because now it uses 7% of cpu while before it used something like 3% in same situation. And it is important, because I notified that by temperature increase.

Answer 21 · 2024-06-13T14:38:27.000Z

This is without clipse, same tabs are open in firefox. Completely different cpu usage graph

Answer 22 · 2024-06-13T14:45:17.000Z

Gotcha @ArtemChandragupta

You shouldn't need to clear everything, likely just a particular image file causing the increased usage so you can try deleting individual files using x, I guess that just takes longer.

Planning to implement more specific clear commands in the future, to specifically clear all images/non-pinned items etc. This is all I can suggest for now though. It's on my radar as something to look into more, let me know if you still get higher than expected usage after removing your images though.

Answer 23 · 2024-06-13T14:55:37.000Z

Issue is still here after clearing the buffer...

Answer 24 · 2024-07-23T16:51:24.000Z

Congratulations! Now (maybe with 1.0.7 patches, while I am on 1.0.9) CPU usage is good on my machine. Now I can say that clipse is my favorite clipboard history project.

Answer 25 · 2024-07-23T20:33:17.000Z

thank you @ArtemChandragupta!