warpdotdev / Warp

Warp is a modern, Rust-based terminal with AI built in so you and your team can build great software, faster.
https://warp.dev
Other
20.96k stars 359 forks source link

performance problems #3502

Open Manubi opened 1 year ago

Manubi commented 1 year ago

Discord username (optional)

No response

Describe the bug

Hi, not a real but just really slow. This can't be real right? a simple 'j dev' takes almost 8sec

How can i debug this?

CleanShot 2023-08-08 at 16 50 02@2x

Thanks!

To reproduce

guess it's my zshconfig which is the problem.

Expected behavior

No response

Screenshots

No response

Operating system

MacOS

Operating system and version

ventura 13.1

Shell Version

zsh 5.9

Current Warp version

latest

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

No

Is this a Warp specific issue? (i.e. does it happen in Terminal, iTerm, Kitty, etc.)

Yes, this I confirmed this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b8107fdf-ba31-488d-b103-d271c89cac3e

None

dannyneira commented 1 year ago

You can check whether it’s something in your dotfiles by setting up clean configs: Run echo 'ZDOTDIR=/' > ~/.zshenv this forces Zsh to run with zero configs.

You can disable parts of your dotfiles just for Warp by using this conditional statement:

# Bash and Zsh
if [[ $TERM_PROGRAM != "WarpTerminal" ]]; then
# > What you want to disable here <
fi

We have a list of incompatible tools here: https://docs.warp.dev/help/known-issues#list-of-incompatible-tools And more info on custom prompts here: https://docs.warp.dev/features/prompt

jessehs commented 1 year ago

This is possibly unrelated to the original poster's issue but I'm also having significant lag that seems to be related to screen size. It also might be related to this issue. I recorded a comparison next to iTerm2 on a 1/2 screen window size of about 1500w x 1660h, as well as a 1/4 window size of about 1500x830. In both cases I was not able to delete text at the max key-repeat rate in Warp, though it was much faster on the smaller window. In iTerm2 the window size did not seem to affect performance.

Before the test I ran the command echo 'ZDOTDIR=/' > ~/.zshenv and restarted both terminals. I also closed most open apps that may have impacted overall system performance.

https://github.com/warpdotdev/Warp/assets/458586/c8250573-41ba-4295-8a3e-de9624236723

stuart-chu commented 7 months ago

I am encountering a performance issue similar to what @jessehs described. After booting up and running for a while with the screen maximized, the input latency in Warp becomes significantly slow. Interestingly, when I reduce the size of the Warp window, this typing delay decreases substantially. It seems the issue is related to how Warp handles input processing at different window sizes, especially when maximized. Has anyone else experienced this, or is there a known workaround?

vorporeal commented 7 months ago

@stuart-chu out of curiosity, does the delay scale as a function of only window height, only window width, or both? might help us track down the cause - only width could point to it being a text layout performance issue, whereas both height+width might point at rendering inefficiencies with respect to the size of the terminal grid itself.

stuart-chu commented 6 months ago

@vorporeal Based on my observations, the input delay does seem to be influenced by both the width and height of the window. The response is very quick when the window size is small. However, when I maximize the window on a 4K monitor, the delay significantly increases. This delay occurs less frequently when using a 2K monitor. Additionally, I've noticed that regardless of whether it's the window's width or height that is reduced, the input delay remains significantly high. This persists even when only one dimension (width or height) is minimized, suggesting that the issue might not be solely related to the overall size of the window. It's worth noting that this delay is not always present; it typically appears after the program has been running for a while. Simply restarting the program does not fix the issue; only a full system reboot seems to provide a temporary fix. This seems to point towards a problem related to rendering efficiency, especially when handling large terminal grids. I hope this information helps in tracking down the specific cause.

saschafuchs commented 3 weeks ago

I have the same problem, I use Warp in Visor Mode. On my 4k screen it is very difficult to highlight text with the mouse due to the lag. If I have the Visor on my MacBook, it works without any problems.