tmux-copycat slow on my machine

[christopher-francisco]

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'

[bruno-]

Hi, yea, the plugin can get be slower as you described. I don't think it's anything related to your config.

…

On 2018-08-04 11:06, Christopher Francisco wrote: I just installed this plugin. I saw the [screencast](https://vimeo.com/101867689) 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' ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #129

[christopher-francisco]

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.

[megalithic]

on latest model 15" macbook pro and definitely seeing extreme slow down on that hardware too..

latest tmux + kitty (term)

[bruno-]

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.

[iryan2]

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?

[neagle]

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.

[cpakkala]

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...

[danijar]

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.

[sabrehagen]

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!

[gpanders]

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.

[gpanders]

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).

[danijar]

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?

[gpanders]

I think this is possible -- I'm not sure if maybe @bruno- or someone else had a reason for not doing this, but since the copycat scripts that we bind those keys to check if we are in "copycat mode" and simply do nothing if we're not, I think it's safe to simply leave those keys bound at all times. I've updated my fork [1] with that change, so feel free to test it out. It's still not as snappy as I think I would like it to be but it is still noticably quicker. [1]: https://github.com/gpanders/tmux-copycat/tree/improve-search-speed

…

On Sun, 03 Nov 2019 at 03:33 PM, Danijar Hafner wrote: 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? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #129 (comment)