bugaevc
Can wl-copy be made faster?
$ time echo test | /usr/bin/xsel --clipboard --input
real 0m0.002s
# https://github.com/bugaevc/wl-clipboard
$ time echo test | wl-copy
real 0m0.052s
# https://github.com/YaLTeR/wl-clipboard-rs/
$ time echo test | wl-copy
real 0m0.002s
I notice the lag because I use it in a snippet manager, which copies the snippet into the clipboard, and then pastes it via wtype -M ctrl -k v -m ctrl.
(Well, I guess the Rust rewrite really is 🦀 blazing fast 🚀 ⚡ :D)
Does it work faster of you specify an explicit type with --type text/plain? If so, that would indicate that it's content type sniffing that's being slow.
Can you think of a way to measure what takes the extra time there?
It makes no sense to measure time echo test anyway. echo will exit as soon as it writes the five bytes to the pipe, and since pipes are buffered, this won't block on anything that the other side of the pipe does.
Does it work faster of you specify an explicit type with --type text/plain? If so, that would indicate that it's content type sniffing that's being slow.
Yes, that works much faster!
# https://github.com/bugaevc/wl-clipboard
$ time echo test | wl-copy --type text/plain
real 0m0.004s
It makes no sense to measure time echo test anyway. echo will exit as soon as it writes the five bytes to the pipe, and since pipes are buffered, this won't block on anything that the other side of the pipe does.
Maybe it's shell specific, but for me, time waits for the entire command (not just the first part before the pipe) to finish:
$ time echo test | sleep 5
real 0m5.002s
In cases where one sequentially does stuff after having copied it into the clipboard (like in my case), this matters, since it halts execution of all upcoming steps.
this could probably be resolved by using a library like libmagic for sniffing content type instead of spawning an xdg-mime child process
