tmux-copycat slow on my machine
christopher-francisco opened this issue · 24 comments
I just installed this plugin. I saw the screencast and it looks very fast. However, on my machine it takes around 1 second to find a match. Not sure what did I do wrong. Here's my tmux config:
unbind C-b
set-option -g prefix C-a
bind-key C-a send-prefix
# don't rename windows automatically
set-option -g allow-rename off
# allow mouse to scroll
set -g mouse on
# scrolling 1 per line
set -g @scroll-speed-num-lines-per-scroll "1"
# themepack theme
set -g @themepack 'powerline/block/gray'
# We want tmux to support 256 colors and allow itallics
set -g default-terminal 'tmux-256color'
set -as terminal-overrides ',xterm*:Tc:sitm=\E[3m'
# List of plugins
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-yank'
set -g @plugin 'tmux-plugins/tmux-copycat'
set -g @plugin 'tmux-plugins/tmux-pain-control'
set -g @plugin 'nhdaly/tmux-better-mouse-mode'
set -g @plugin 'jimeh/tmux-themepack'
# Initialize TMUX plugin manager (keep this line at the very bottom of tmux.conf)
run '~/.tmux/plugins/tpm/tpm'
Are you sure? in the screencast it looks blazing fast. Maybe there's something I can do to make it faster(?)
Unbearably slow on my setup as well, hope to get around to profiling....
Looks to be disk bound performance issues (at least for me)... not sure if its just the amount of external sourcing of bash files or if its that I am an oddball on nixos package manager/wsl. I'll try again later on a less akward setup.
The ~3 seconds for the command to take action kind of matches up with the disk activity in task manager. I'm running a 960 pro, so disk work should be pretty fast.
on latest model 15" macbook pro and definitely seeing extreme slow down on that hardware too..
latest tmux + kitty (term)
Are you guys running large tmux scrollback histories, the set -g history-limit option? If the value of that option is large and you have big pane history I can see how this would need more time. Copycat dumps tmux's history to a file and then searches that file. The bigger the history the more time some of these actions can take.
I use set -g history-limit 5000. The speed on my machine is not snappy, but not slow either.
I've set history-limit as suggested and in a fresh tmux session it takes about 1s to find a match, pressing n takes roughly 350ms to go to next match. Any ideas on how to bring this down?
I'm having trouble, too; using the set -g history-limit 5000, I used tmux kill-server to start over, then typed tmux to start a new session. I entered echo "http://www.somewebsite.com", then ctl+prefix + ctl + U. It took about three seconds to find the result. This is on a 2018 MBP.
I first began noticing this problem sometime last year; there definitely was a time when it seemed as snappy as in the screencast.
I definitely don't mean to complain: the only reason this is a problem is because the plugin is incredibly useful. But I'd love it if anyone had any insight into what might be going on: this speed makes it a little hard to rely on the plugin the way I used to.
I too would love to be able to use this plugin; however it's unbearably slow for me (it takes multiple seconds after pressing my keybinding for anything to happen) and I believe the culprit is I/O. I work on NFS mounts almost exclusively and the temporary files that copycat is writing are being made in the $CWD. If the temporary directory were made configurable, I could point it to /tmp or /dev/shm (memory) which would make this usable. Please consider making it configurable or make it respect the standard TMP, TMPDIR or TEMP environment variables.
update: My bad, I see that _get_tmp_dir() does use TMPDIR. Guess I'm going to have to find a better way to profile this...
What's the reason for dumping the buffer to a text file before searching it? I'd be happy to help make this faster. The plugin is a great idea but right now unfortunately pretty annoying to use.
What's the reason for dumping the buffer to a text file before searching it? I'd be happy to help make this faster. The plugin is a great idea but right now unfortunately pretty annoying to use.
Do you have time/capacity to action this? A lot of people would be very thankful!
I did some digging and it looks like the slowness is not caused by dumping the buffer first. By default, copycat dumps up to 9,000,000 scrollback lines, but changing this to even 100 does not make a noticeable difference.
Instead, the bulk of the "lag" comes in the copycat_cancel_bindings function. Whenever copycat mode is started, copycat extends the keybindings it needs for both searching and cancelling. To do this, it parses the output of tmux list-keys for every key to re-bind the key with its extended value.
For copycat_cancel_bindings, this is up to about 11 different keys, in addition to the standard "next" and "prev" keys. You can see this for yourself: if you comment out line 53 of copycat_mode_bindings.sh you'll see a noticeable improvement in speed (although this will mess things up).
I am not yet sure what the solution is, but at least now we know where the problem is.
I was able to get a little bit of improvement in my fork here. There is still a delay, although in my (limited) testing it does seem to be significantly less than it is now. I think the remaining delay comes from the actual calls to tmux bind-key which cannot really be optimized (they have to be done one at a time).
Would it be possible to bind the keys (maybe different ones to avoid conflicts) once during startup rather than every time copy mode is entered?
Thanks @gpanders, the changes on your branch make a big difference on my machine... as in this plugin is usable again for me 🙌
@gpanders's changes make this indeed faster and like they said it still isn't as fast as one would like it's already a huge improvement as this plugin is once again usable, kudos! It also got merged to master over a month ago so no need to do like I did and replace the official release with his branch :)
Don't know if this can be regarded as solved though. I'd guess yes and any future performance issues should go to a new ticket since this has gotten stale and there already are some performance improvements implemented after filing the ticket.
@okuuva Due to the email I received when you commented, I reinstalled my tmux packages and am happy beyond my ability to describe to find that copycat is much faster than it was. Maybe it could be faster still, but—for me—it's definitely back into the very usable category. Thanks to everyone who helped improve the situation.
Also chiming in to confirm this is fast enough to be useful again! 🙌
Damn! it's blazing fast!! I love it!
Can we get a link to the commit/PR, in case anybody wants to work on an improvement?
It's amazing now. I agree that it could be better, however it is good enough to be usable in a workflow. Love you guys!!
Hey @gpanders! I saw your fork and I wanted to try it out. I didn't notice changes in speed so I wanted to confirm the way I am installing it. I did a manual installation and cloned the library and called copycat.tmux in the cloned repo of your fork.
I observed similar speeds but a lot of folks were saying that speeds heavily improved for them so I wanted to confirm my way of installing your fork.
Hi @hqkhan, my changes were merged into this repo back in January, so you won't see any difference between my fork and this repo right now.
Gotcha. That's odd because I tried the repo first and it was really slow for me. I am on WSL-1 and tmux 3.0a.