search

zellij-org / zellij

A terminal workspace with batteries included
https://zellij.dev
MIT License
20.87k stars 638 forks source link

Slow down on opening #1757

Open fulljackz opened 2 years ago

fulljackz commented 2 years ago

Hi,

Since version 0.31.0, I have a performance issue when I start zellij. I'm using zellij with Tilix and zsh.

When I open a new terminal using my shortcut : + , if I spam my keyboard 3x on letter A, only one or two letters appears. It gives the impression that the focus is not on the window yet, for 1 second or a little bit more.

I noticed that this "regression" appeared with the 0.31.0 release and was not present before.

I tried using bash + Tilix, zsh + Tilix, zsh + Gnome Terminal, bash + Gnome Terminal : same behavior.

Basic information

zellij --version: zellij 0.31.4 stty size: 44 183 uname -av: Linux LIN-ELN 5.19.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Tue Aug 2 07:35:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

You'll find log in attachement. I hope I can help for debug or tests.

Regards,

zellij.log

stouset commented 2 years ago

Yeah, it appears zellij pauses for 1+ seconds before accepting keyboard input. This frequently causes me to lose several keystrokes.

har7an commented 2 years ago

Thanks for reporting this @fulljackz and @stouset,

unfortunately I can't reproduce this issue. If I open a new pane and hammer around on my keyboard immediately afterwards it doesn't lose a single keystroke.

To eliminate influence from configs or such I ran it in the following environment:

But even on my host all keystrokes are registered. Could you detail your working environments a little more? Do you use some special shell prompts or other shell customizations?

fulljackz commented 2 years ago

Hi @har7an , thx for reply.

Here are some details about my config :

Even if I use bash shell (without customization), same behavior. I tried to record a screencast but it does not mean many things as far as you nobody see my fingers on my keyboards :laughing:

I dont really know how to help but dont hesitate if I can try things etc.

Note that before 0.31.0, I can't reproduce it and everything is very fast at opening :thinking:

har7an commented 2 years ago

That's very interesting, because as far as I can gather most of the changes in 0.31.0 related to the terminal and "backend" code actually improved performance.

I'll go through the changes and see if something sticks out. Thanks for the detailed information, I'll get back to you when I found something!

imsnif commented 2 years ago

Hey, this happens because we query the terminal emulator on startup for things like pixel-size/cell ratio, color palette, etc. We can't yet respond to STDIN from the user until this is done.

Sorry, I know this is a somewhat weird behavior but it was unavoidable here. IMO the best way to solve this would be to only render the UI while this is happening. Ideally to also visually indicate this to the user: Querying Terminal for Pixel / Color info... or some such.

stouset commented 1 year ago

Is it possible to accept STDIN from the user while this is happening, even if you can't respond until it's finished? That could simply be replayed to the terminal once it's available.

imsnif commented 1 year ago

Unfortunately not - I agree that would have been best. But we have no way of differentiating what the user typed and what the terminal emulator sends us (that I know of, at least!) So much so that if you type something while the terminal emulator is still sending us this info, the info will get corrupted and we won't parse it properly.

imsnif commented 1 year ago

Worst case that would happen is that we won't respond correctly to ANSI color queries or have to make guesses regarding the pixel to cell ratio. So no biggie there.

mo8it commented 1 year ago

@imsnif I wonder how shells like fish and bash handle this problem. Don't they have to fetch information from the terminal emulator too? When I start fish, I can press keys and they are showed after around 1 sec, but they are at least accepted.

imsnif commented 1 year ago

I don't think they fetch that sort of information... at least I don't remember seeing this the last time I looked at the raw fish startup STDOUT.

I think this is a uniquely Zellij problem - seeing as tmux or screen don't support these ANSI sequences. I can possibly try to reduce it to less than a second. Will try to play around with it when I have time.

mo8it commented 1 year ago

I have no idea how this fetchting of terminfo is implemented in Zellij, but one idea would be to fetch the info in a separate process with its own STDIN and join it before rendering?

taind772 commented 1 year ago

Ideally to also visually indicate this to the user: Querying Terminal for Pixel / Color info... or some such.

It's weird, I don't care much about opening slow down, but does Zellij have the option to hide those messages from startup? Or can we cache the result? Those settings are rarely changed and waste ~1 second every time stating the app makes Zellij feel much slower.

jakubkaczor commented 7 months ago

I have a similar issue and I have found the cause of it. In my case, lots of exited but eligible for resurrection sessions caused the slowdown. I have noticed list-sessions subcommand take a lot of time to execute. It listed 365 entries. All the listed sessions, apart from the current one, were exited, but eligible for resurrection. Running zellij delete-all-sessions reduced the start-up time enough, so I do not consider it an issue. Now, it is similar to the one before I noticed the problem.

I suppose it is necessary to read sessions at startup, but is it necessary to do it for the exited sessions? If it is, then it would be nice to have a configuration option limiting the number of serialized sessions. I have only found the option for controlling the number of scroll back lines serialized.

For now, setting session_serialization to false alleviates the issue, but at the cost of the resurrection functionality.

I am surprised that I haven't noticed a gradual build up in the start-up time, but it appeared that after some update the start-up time increased at least 1 second. Perhaps there is some limiting value for the number of sessions that causes a significant slowdown, or, indeed, some change introduced a regression in session listing time. I cannot tell if I experienced the problem after some update or not.

Andrew15-5 commented 1 month ago

I can only reference https://github.com/zellij-org/zellij/issues/3162, which describes the exact problem I faced. This issue can be a duplicate of that.

Even though I mostly close all sessions with exit I still see a pile of dead sessions in the cache (the cache was around 0.5 GiB). I don't think it should pile up so much (maybe I use a wrong workflow or zellij's resurrection feature just doesn't play nice with general usage over time), but in any case, removing shell's config and then adding exit in it creates a nice benchmark (don't forget to have a backup shell open to restore the config).

Just run zellij or time zellij and it will immediately exit the shell when zellij will load one. It previously took 1 s, but now it says 0.07–0.12 s. I guess this is pretty fast for a complex program.

P.S. I should clean up my config, as it alone adds another 0.7 s or so.