tmux 3.4 stalls during active pane zoom

[Dom Delnano]

Since upgrading to Ubuntu noble, I've noticed that the tmux server stalls when zooming the active pane (prefix + z). Using top -p ${tmux_server_pid} its easy to see that the server will sometimes consume as high as 60% CPU when servicing this zoom pane operation.

Rebuilding tmux from upstream the current 3.4 tag doesn't seem to experience this issue:
```
ddelnano@dev-vm:~/code/tmux ((3.4)) $ git rev-parse HEAD
9ae69c3795ab5ef6b4d760f6398cd9281151f632
```

I've collected flame graphs of the buggy upstream version and a self built 3.4 binary attached to this report.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: tmux 3.4-1build1 [modified: usr/bin/tmux]
ProcVersionSignature: Ubuntu 6.8.0-1007.7-gcp 6.8.1
Uname: Linux 6.8.0-1007-gcp x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
CasperMD5CheckResult: unknown
CloudArchitecture: x86_64
CloudBuildName: server
CloudID: gce
CloudName: gce
CloudPlatform: gce
CloudRegion: us-west1
CloudSerial: 20240423
CloudSubPlatform: metadata (http://metadata.google.internal/computeMetadata/v1/)
Date: Thu May 23 13:58:20 2024
SourcePackage: tmux
UpgradeStatus: No upgrade log present (probably fresh install)

[Mitchell Dzurick (mitchdz)]

Thank you for making this bug report Dom!

I've been unable to reproduce this error that you're showing.

I tried on my noble laptop, a noble LXC container, and on an AWS EC2 instance.

How are you creating the panes? Maybe there's a weird bug if you zoom in a certain pane configuration, I've just attempted simple horizontal/vertical split.

I see gce as the CloudPlatform, how are you connecting to the tmux server? Are you simply ssh'ing into the machine and running tmux?

[Romain Francoise (rfrancoise)]

I'm not sure the flame graph of the locally built tmux captures the same thing. In any case, zooming/dezooming causes a grid reflow which basically reallocates the entire grid of rows shown on screen. If you have a sufficiently large window, it can be slow.

In this specific instance it would seem that for the packaged tmux, the AVX implementation of memmove() is being used and it's unusually slow. Is AVX emulated in GCE?

[Dom Delnano (ddelnano)]

Sorry for the late reply. I'm creating the panes through the following commands:
- split-window -c '#{pane_current_path}'
- split-window -h -c '#{pane_current_path}'
- split-window -h -c '#{pane_current_path}'

It's worth noting that I usually replicate the session pane configuration above once per code repository. I'm connecting to the tmux server by ssh'ing to the GCE instance and running `tmux attach`. I've attached my tmux.conf file as well.

[Dom Delnano (ddelnano)]

> If you have a sufficiently large window, it can be slow.

I'm experiencing the same slowness with my Macbook Air and a desktop machine. The former has a 13 inch screen and the latter has a much bigger monitor.

To rule out the emulated AVX issue being the sole problem, I am seeing the same behavior on a xen (4.18) Noble VM running on dedicated hardware. That machine is using a Intel(R) Xeon(R) Gold 6222 CPU @ 1.80GHz CPU

[Romain Francoise (rfrancoise)]

Does the same bug occur without your ~/.tmux.conf?

[Dom Delnano (ddelnano)]

It seems that a recently launched tmux server behaves better and the performance gets worse over time. With that anecdotal evidence, it's hard to say if my tmux.conf influences the slowness but it seems to slow down the longer run it without my configuration.

Is there any interesting information I can collect during the degradation that would inform what is happening during the grid reflow/reallocation?

[Romain Francoise (rfrancoise)]

All the symptoms point to a known issue where tmux gets slow if `history-limit` is set to a stupidly high values (in the millions) but yours is set to a very reasonable 30000. The default is 2000.

You don't have a Sixel image in your shell prompt or something expensive like that, I presume.

[Sergio Durigan Junior (sergiodj)]

Hi Dom,

I noticed from your tmux.conf that you have Tmux Plugin Manager installed and enabled. Could you try reproducing the issue without tpm, please? We should rule out any third-party influence here.

Thanks.