Neovide takes a long time to launch on Windows 11

[figurae]

Describe the bug
Neovide takes a long time to launch on Windows 11 when launched using the icon. I haven't measured it but it's around 2 seconds compared to less than 1 second it took before 0.11.2, so it's ~2-3 times slower.

I bisected a bit and the culprit seems to be 937decd. It looks like on Win11, this approach has to launch the console first to check nvim version (and I think it's even launched twice, as there are two windows that appear and disappear before Neovide itself launches), and on Win11 this takes a really long time.

Oh, and it also launches a bit longer than pre-0.11.2 when launched from the command line, but it's not as dramatic compared to launching from the icon.

To Reproduce
Steps to reproduce the behavior:

1. Launch Neovide 0.11.2 on Windows 11 by double clicking its icon
2. See that it has to launch two windows before launching Neovide and that it takes time

Expected behavior
I would like the previous startup time back, please. One of the main reasons I'm using modal editors is that they launch extremely quickly. If not by reverting to the previous method on Windows, then maybe by caching the information received using the new method or by providing an option to specify it manually so that Neovide doesn't have to check it every time?

Desktop (please complete the following information):

• OS: Windows 11 10.0.22621
• Neovide Version 0.11.2 and 937decd
• Neovim Version 0.9.2

Please run neovide --log and paste the contents of the .log file created in the current directory here:
Surely that's not a real requirement, it's like 0.5 MB... attached instead.
neovide_rCURRENT.log

[MultisampledNight]

Hi, thanks for reporting!

I believe the relevant change comes from #1946, specifically the delay of the fork and window creation until the neovim instance has been constructed (and confirmed its versions matches). Could you (or someone who can reproduce it, I'm not on Windows) test before and after #1946? If it's not fast before it either, could you try a release where it worked fine and git bisect to find the relevant commit?

If #1946 is the cause, the reason for the move was to be able to detect Neovim errors before real launch and still print them if possible. A feasable approach for solving could be imo constructing the neovim instance on the neovim comms thread like before if one of both:

1. A commandline option --i-know-what-i-am-doing or --no-check-neovim-bin as a manual override is passed, as you mentioned.
2. One of stdout and stderr doesn't point to a terminal.

However, I don't think caching would be a good solution, specifically since it's unclear when the cache should be invalidated.

[figurae]

Hi, thanks for replying.

I already did bisect it, I just linked to the master commit instead of PR. It is indeed #1946 as commits before its merge are fast :)

I have no objections to your proposed solution.

[MultisampledNight]

...wow, I should read more thoroughly, I apologize! The first check should be relatively trivial, and we did discuss doing something like the second check for something else (?) on the Discord anyway, I'll see what I can hack up. Maybe I'll do it on the weekend.

[figurae]

No problem, thanks for all your hard work! <3

[fredizzimo]

It looks like before those changes it started the WSL two times. Once for exists -x (which always failed, since there is no such command). I'm not sure that it has ever worked, it probably didn't. I added that myself two years ago, so I only have myself to blame for that, maybe I messed up some refactoring after testing or something. I'm pretty sure I meant to use test -x, but that is shell dependent, so it's not really suitable and was therefore changed to nvim -v for a more robust detection.

Anyway. I don't think a failing or non-failing command should be that much different, since it's the startup time of wsl.exe that matter. So, the end result is the same as calling wsl.exe twice.

But the difference is that it now calls wsl three times by default, one for which, once for nvim -v and then the final time for starting the actual executable.

You can get rid of one of them by specifying the path to nvim, which should speed it up a bit. neovide --neovim-bin /usr/sbin/nvim, or wherever it is on your system. That gets rid of the which call.

But if your goal is fast opening of files, then perhaps another approach is more suitable, launching WSL will always be slow whatever we do.

One way to do it, is to keep Neovide running the whole day, and use https://github.com/mhinz/neovim-remote to open the files. That's what I use myself when I'm on Windows, and I even have the git editor configured to use that.

EDIT. I think we can get rid of which completely on wsl, since it’s always the shell that launches it

[oabt]

For me, a temporary solution is that, in "windows terminal" settings, set default terminal application to "windows console host" rather than the "windows terminal".
This makes neovide 0.11.2 launch faster but still not that fast like 0.11.1.