Slow startup time on WSL2

[galah92]

Summary

I've install Helix on WSL2 (default Ubuntu distro) through apt. Startup time of the editor is significantly slower then vim.
I imagine something is misconfigured correctly out of the box, but not sure what.
This is true for when I'm opening hx without a file path, and with different file types (.rs, .ts, .txt).

Reproduction Steps

Note sure how helpful it is, but:

galah92@Dell14:~/adventofcode$ time hx src/main.rs
real    0m44.999s
user    0m0.807s
sys     0m0.285s
galah92@Dell14:~/adventofcode$ time vim src/main.rs

real    0m1.066s
user    0m0.054s
sys     0m0.022s

I think the user / sys parameters here are the relevant ones. It definitely feels like its takes 1-2 seconds to startup.

Helix log

~/.cache/helix/helix.log

galah92@Dell14:~$ cat ~/.cache/helix/helix.log
2023-06-03T13:46:13.911 helix_vcs [ERROR] Error {
    context: "failed to open git repo",
    source: Discover(
        NoGitRepository {
            path: "/home/galah92",
        },
    ),
}
2023-06-03T13:46:13.911 helix_vcs [ERROR] failed to open diff base for /home/galah92/.bashrc
2023-06-03T13:46:13.911 helix_vcs [ERROR] Error {
    context: "failed to open git repo",
    source: Discover(
        NoGitRepository {
            path: "/home/galah92",
        },
    ),
}
2023-06-03T13:46:13.911 helix_vcs [ERROR] failed to obtain current head name for /home/galah92/.bashrc
2023-06-03T13:46:14.146 helix_view::editor [ERROR] Failed to initialize the LSP for `source.bash` { cannot find binary path }

Platform

Linux (WSL2)

Terminal Emulator

Windows Terminal

Helix Version

helix 23.03

[Tudyx]

I think it might have been fixed in #7028
Please try to update to Helix 23.05 that contains this fix.

[galah92]

Isn't this fix specific for .ts files? What I'm experiencing is relevant for all file types and even when opening the editor without a specific file (empty buffer).

[Tudyx]

Yes you are right, does you still have the problem with the latest version though?

[christianfosli]

I found something similar a while ago, where it turned out to be because I had a misconfigured X-server in my WSL distro, and helix's clipboard logic was waiting for xsel to time out (#3083). Possibly relevant?

[galah92]

@christianfosli tried that just now, unfortunately it doesn't help.

[pascalkuthe]

Isn't this fix specific for .ts files? What I'm experiencing is relevant for all file types and even when opening the editor without a specific file (empty buffer).

No tree sitter is the syntax highlighting used for every language so that PR might help altough not super likely.

[iceghost]

Apparently it is due to Helix scanning the PATH for some non-existent binary upon opening. Accessing Windows PATH inside WSL is slow, so it took quite some time for Helix to start up. Disabling Windows PATH inside WSL helped me fix this issue.

# inside /etc/wsl.conf
[interop]
appendWindowsPath = false

(But I guess, installing that missing binary could help too, but I don't know what that is)

[pascalkuthe]

We are searching for the LSP binary when opening a file. It might be reasonable to start LSPs async (since it generally involves a decent amount of I/O anyway) to speedup startupt

[the-mikedavis]

It could be the clipboard provider binary too

helix/helix-view/src/clipboard.rs

Lines 95 to 144 in d6856cf

	pub fn get_clipboard_provider() -> Box<dyn ClipboardProvider> {
	use crate::env::{binary_exists, env_var_is_set};
	use provider::command::is_exit_success;
	// TODO: support for user-defined provider, probably when we have plugin support by setting a
	// variable?
	if env_var_is_set("WAYLAND_DISPLAY") && binary_exists("wl-copy") && binary_exists("wl-paste") {
	command_provider! {
	paste => "wl-paste", "--no-newline";
	copy => "wl-copy", "--type", "text/plain";
	primary_paste => "wl-paste", "-p", "--no-newline";
	primary_copy => "wl-copy", "-p", "--type", "text/plain";
	}
	} else if env_var_is_set("DISPLAY") && binary_exists("xclip") {
	command_provider! {
	paste => "xclip", "-o", "-selection", "clipboard";
	copy => "xclip", "-i", "-selection", "clipboard";
	primary_paste => "xclip", "-o";
	primary_copy => "xclip", "-i";
	}
	} else if env_var_is_set("DISPLAY")
	&& binary_exists("xsel")
	&& is_exit_success("xsel", &["-o", "-b"])
	{
	// FIXME: check performance of is_exit_success
	command_provider! {
	paste => "xsel", "-o", "-b";
	copy => "xsel", "-i", "-b";
	primary_paste => "xsel", "-o";
	primary_copy => "xsel", "-i";
	}
	} else if binary_exists("win32yank.exe") {
	command_provider! {
	paste => "win32yank.exe", "-o", "--lf";
	copy => "win32yank.exe", "-i", "--crlf";
	}
	} else if binary_exists("termux-clipboard-set") && binary_exists("termux-clipboard-get") {
	command_provider! {
	paste => "termux-clipboard-get";
	copy => "termux-clipboard-set";
	}
	} else if env_var_is_set("TMUX") && binary_exists("tmux") {
	command_provider! {
	paste => "tmux", "save-buffer", "-";
	copy => "tmux", "load-buffer", "-w", "-";
	}
	} else {
	Box::new(provider::FallbackProvider::new())
	}
	}

[iceghost]

It could be the clipboard provider binary too

helix/helix-view/src/clipboard.rs

Lines 95 to 144 in d6856cf

	pub fn get_clipboard_provider() -> Box<dyn ClipboardProvider> {
	use crate::env::{binary_exists, env_var_is_set};
	use provider::command::is_exit_success;
	// TODO: support for user-defined provider, probably when we have plugin support by setting a
	// variable?
	if env_var_is_set("WAYLAND_DISPLAY") && binary_exists("wl-copy") && binary_exists("wl-paste") {
	command_provider! {
	paste => "wl-paste", "--no-newline";
	copy => "wl-copy", "--type", "text/plain";
	primary_paste => "wl-paste", "-p", "--no-newline";
	primary_copy => "wl-copy", "-p", "--type", "text/plain";
	}
	} else if env_var_is_set("DISPLAY") && binary_exists("xclip") {
	command_provider! {
	paste => "xclip", "-o", "-selection", "clipboard";
	copy => "xclip", "-i", "-selection", "clipboard";
	primary_paste => "xclip", "-o";
	primary_copy => "xclip", "-i";
	}
	} else if env_var_is_set("DISPLAY")
	&& binary_exists("xsel")
	&& is_exit_success("xsel", &["-o", "-b"])
	{
	// FIXME: check performance of is_exit_success
	command_provider! {
	paste => "xsel", "-o", "-b";
	copy => "xsel", "-i", "-b";
	primary_paste => "xsel", "-o";
	primary_copy => "xsel", "-i";
	}
	} else if binary_exists("win32yank.exe") {
	command_provider! {
	paste => "win32yank.exe", "-o", "--lf";
	copy => "win32yank.exe", "-i", "--crlf";
	}
	} else if binary_exists("termux-clipboard-set") && binary_exists("termux-clipboard-get") {
	command_provider! {
	paste => "termux-clipboard-get";
	copy => "termux-clipboard-set";
	}
	} else if env_var_is_set("TMUX") && binary_exists("tmux") {
	command_provider! {
	paste => "tmux", "save-buffer", "-";
	copy => "tmux", "load-buffer", "-w", "-";
	}
	} else {
	Box::new(provider::FallbackProvider::new())
	}
	}

Yes, I think this is the cause! unset DISPLAY and unset WAYLAND_DISPLAY works, short-circuiting to win32yank.exe and makes it startup multiple time faster.

EDIT: Ah, I realize I could just

sudo apt install wl-clipboard

and call it a day, as WSL has support for Wayland stuff. This is much faster now.

[pascalkuthe]

I guess that just means we can make searching for any binary (clipboard provider or LSP) async? It's kind of unfortunate and seems like a WSL problem gir the mist part but I guess not doing IO on the main thread is generally good practice

[matthewlloyd]

As a first-time Helix user on WSL2, this was something I noticed almost immediately. Googled and found this issue. sudo apt install wl-clipboard completely fixed it for me and it now starts up instantaneously, just like vim. Thank you!

[LowLevelLover]

As a first-time Helix user on WSL2, this was something I noticed almost immediately. Googled and found this issue. sudo apt install wl-clipboard completely fixed it for me and it now starts up instantaneously, just like vim. Thank you!

Thanks, this solved my issue.