zellij is slow (alacritty or default terminal)

[PSeitz]

When moving the cursor or scrolling, there is visible delay, also in comparison to tmux. I tested with alacritty and with the linux mint default terminal.

Basic information

zellij --version: zellij 0.13.0 tput lines: 34 tput cols:115 uname -av: Linux pascal-G533QM 5.12.0-051200-generic #202104252130 SMP Sun Apr 25 21:33:13 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

nvim --version: NVIM v0.5.0-dev+1274-gbb3372792 (used the appimage release) alacritty --version: alacritty 0.8.0

Further information I just opened a file in nvim in alacritty and did scroll a little bit in the logs below.

zellij-7.log zellij-8.log zellij-9.log

Related Issue: https://github.com/zellij-org/zellij/issues/443

[imsnif]

@PSeitz - from looking at the logs, it seems to me that your terminal window is actually considerably larger than 33/88 - am I missing something? Looks like you have ~70 lines on screen and somewhere in the neighbourhood of 360 columns?

If that's the case, any chance you can reproduce this on a smaller pane? About half the size? My screen is not so big and it's very hard for me to debug it like this (I have to reduce the text size considerably and squint at the screen :) ).

[imsnif]

Btw, playing around with these sizes (88 lines on 388 cols) - Zellij is indeed a little slow to react on my machine. Is this your bug?

[PSeitz]

@imsnif oops I restarted the terminal before tput. I updated the files with a smaller window.

Btw, playing around with these sizes (88 lines on 388 cols) - Zellij is indeed a little slow to react on my machine. Is this your bug?

Yes, it feels like 15fps instead of 60

[imsnif]

@PSeitz - no worries... does it still feel slow to you in a smaller window? I'm trying to zero in on what this bug is exactly...

[PSeitz]

It's still slow in a small window. I can't really tell if the size affects the performance. I don't think so, but could be a little bit.

[imsnif]

Hrm... I'm not reproducing this by cating the log file (it doesn't mean anything, it can be lots of other things). Does this only happen when scrolling in neovim? Can you reproduce it with vim? How about with just throwing lots of lines into the terminal (eg. cating a large file)?

[PSeitz]

when cating I can't see a difference, but it's also visible on the command line when typing and removing something.

I think it could be caused by two things, either the drawing is too slow and therefore it lags. It doesn't seem to correlate to larger screen sizes, so probably it would be some expensive calculation in each draw independent from screen size.

The other possibility is that a screen redraw is not triggered often enough.

[imsnif]

That's interesting. If you don't see a difference when cating a large file, then it's not likely to be the drawing speed or how often the render function is called. Because that would affect it as well (it's a very large cat, right? should ideally be something in the neighbourhood of 100K lines or so? for me in Zellij it takes ~200ms to cat such a file).

I have two theories right now:

1. The lag is actually coming from STDIN. What you're seeing is not slow rendering but slow response to keyboard commands (also a bug in Zellij, but in a different place)
2. The lag happens because the program running inside the terminal (eg. vim or the shell) is querying the terminal emulator for theme information (eg. background color) using OSC signals and Zellij responds too slowly. Programs often do this to know if they should render a light or dark colorscheme.

The first issue might be a little easier to debug. An idea that came to my mind is to try to either:

1. Create a loop in the command line that does something that would be slow to render through the keyboard, measuring how much time every iteration takes (eg. with date or time, depending on what you're doing) and seeing if you see the same lag you do when entering the commands manually.
2. Do something similar, but with a macro in neovim

Are you comfortable helping me debug this further? I appreciate your help on this. It's a pity I can't reproduce this myself and investigate without troubling you like this. :/

[PSeitz]

Here are the numbers of cat of a 10mb file. It's interesting that the numbers don't add up.

Raw
Executed in  183,71 millis    fish           external
   usr time    0,40 millis  398,00 micros    0,00 millis
   sys time   88,60 millis  230,00 micros   88,37 millis

zellij
Executed in  274,50 millis    fish           external
   usr time    0,33 millis  330,00 micros    0,00 millis
   sys time  105,38 millis  198,00 micros  105,18 millis

tmux
Executed in  273,52 millis    fish           external
   usr time    0,42 millis  423,00 micros    0,00 millis
   sys time   96,10 millis    0,00 micros   96,10 millis

For 1. I think a simple echo with a sleep in a loop should be fine. I can see it lagging in comparison with tmux.

while true
    echo "Loop forever"; sleep 0.01;
end

I can also created a perf profile, here is the timeline overview.

[imsnif]

Thanks! Is the profile from the loop or the cat, or something else?

[PSeitz]

The profile is from the loop

[imsnif]

So, tbh I don't see anything wrong with this profile (unless I'm missing something?) What sort of lag are we talking about? Does it accumulate? Does the loop become slower over time? Do you still feel it if you change the sleep to 0.1 instead?

[PSeitz]

The lag does not accumulate, it looks like it is locked to 20fps all the time. With 0.1, which would be 10 fps, it looks the same.

I don't see something obvious, but some possible culprits which may block the cpu each frame and therefore lowering the fps. (screen, wasm, async-io)

[imsnif]

I see. I understood this issue a bit differently before. So seems like we're talking about frame-rate mostly, and the delay we're talking about is quite minuscule. Not saying it's not a bug still, but good to put it in context. :)

I think I know where this is coming from if this is the case. We have a hard-coded delay of 30ms when polling the pty. I can examine lowering it (I think after the recent performance improvements we don't need it anymore). Would you be comfortable running a custom version of Zellij that I'll attach here with the sampling rate lowered to see if it looks better for you? Or would you prefer I push the changes to a branch and you compile and run it yourself to test?

[PSeitz]

Yes that's it! I changed that to 3 and it's smooth now. https://github.com/zellij-org/zellij/blob/056f20ff1f90cd75c03fefda6ef8371c2adeabb7/zellij-server/src/pty.rs#L171

[imsnif]

That's great! I'm not super thrilled about changing this number (because it might be detrimental to systems with less resources) - but I have an idea that might address this. I'll push it to a branch and ping you to try it.

[imsnif]

@PSeitz - how does it look with a 10ms render_pause? I found that 3ms actually decreases performance (even though the frame rate is rather high), but I think 10ms should be a good middle-ground.

[jesse-osiecki]

I believe it is related, Vim scrolling/cursor is choppy. It reminds me of a non-double-buffered video game. I'll try gathering more data than casual observation

[Gnurou]

Hi everyone, new user here. I was feeling some kind of input latency compared to my previous multiplexer and found this issue, in particular the comments about changing render_pause. This led me to quickly put #798 together to address this. It may not fix all the problems reported here, but at least it helps reduce the perception of latency - please take a look!

[PSeitz]

Hi everyone, new user here. I was feeling some kind of input latency compared to my previous multiplexer and found this issue, in particular the comments about changing render_pause. This led me to quickly put #798 together to address this. It may not fix all the problems reported here, but at least it helps reduce the perception of latency - please take a look!

Awesome, it's very fluent now for me, closing it.

[fixapc]

Can we get a change on this so we dont have to recompile from src? This seems like it should be addressed as this is easily noticeable.

[imsnif]

@fixapc - we don't have a render pause at all right now and instead start chunking things up only when we get congested. If things are slow for you, it might be some sort of environmental issue.

[fixapc]

@imsnif Ya i just noticed that my self XD, turned out to be cgroups being over protective of my resources when i was compiling. Just installed this and so far its much better than tmux and overall much easier for me to implement in my current work flow.

[imsnif]

Happy tohear this @fixapc ! Would you be willing to write something more detailed about this so we can put this in some troubleshooting section? Or even just leave it in this issue? I haven't heard of this and it might help others.