elves
30 second startup delay on windows
What happened, and what did you expect to happen?
Hi, I'm new to elvish. It looks like a fun crossplatform shell that I'm considering as replacement for nushell. However, I'm having a strange issue.
Elvish.exe suffers from startup delays of about 20-30 seconds on my work windows laptop. I'm not sure why. I don't have any rc.elv. Usually it happens the first time I start it, then for some time new instances spawn instantly, but then after a minute or so it's slow again.
On WSL this problem does not occur. On my personal windows PC it also does not occur.
It does not matter which terminal emulator I use.
However, it does not seem to be an Anti-Virus issue at first glance, since windows defender does not report any action.
Deploying a windows dev-drive or adding exclusions to the windows virus scanner also does not change the startup delay.
Moreover, elvish -h does not have the delay, so it's really caused by something that is done by elvish.exe.
Daemon Log
[daemon] 2025/04/25 09:52:43 pid is 30160
[daemon] 2025/04/25 09:52:43 going to listen (...)\sock
[store] 2025/04/25 09:52:43 initializing store
[store] 2025/04/25 09:52:43 initialized store
It hangs after this line, but no messages are written after that.
Procmon events in the slow case:
"6:44:42.7799126 PM","elvish.exe","10112","RegQueryValue","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Domain","SUCCESS","Type: REG_SZ, Length: 2, Data: "
"6:44:42.7799246 PM","elvish.exe","10112","RegCloseKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters","SUCCESS",""
"6:45:04.9706849 PM","elvish.exe","10112","CreateFile","\\AzureAD\PIPE\samr","BAD NETWORK PATH","Desired Access: Generic Read/Write, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a"
"6:45:04.9712146 PM","elvish.exe","10112","RegOpenKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters","REPARSE","Desired Access: Read"
"6:45:04.9712476 PM","elvish.exe","10112","RegOpenKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters","SUCCESS","Desired Access: Read"
Same chunk in the fast case:
"9:44:08.7834101 AM","elvish.exe","100080","RegQueryValue","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Domain","SUCCESS","Type: REG_SZ, Length: 2, Data: "
"9:44:08.7834223 AM","elvish.exe","100080","RegCloseKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters","SUCCESS",""
"9:44:08.7835562 AM","elvish.exe","100080","CreateFile","\\AzureAD\PIPE\samr","BAD NETWORK PATH","Desired Access: Generic Read/Write, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/a"
"9:44:08.7836671 AM","elvish.exe","100080","RegOpenKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters","REPARSE","Desired Access: Read"
"9:44:08.7836763 AM","elvish.exe","100080","RegOpenKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters","SUCCESS","Desired Access: Read"
Even though the second case is fast, it could still be the case that it has something to do with the \\AzureAD\PIPE\samr network call.
What could be doing that network call, and can I trouble shoot by tweaking elvish settings?
Hypothesis
To me \\AzureAD\PIPE\samr looks like a windows domain related network lookup, possibly done indirectly to retrieve information about the current user.
I'm not a Go programmer, but I read on the internet that os/user.Current() can possible cause delays.
I found https://github.com/golang/go/issues/68312
Output of "elvish -version"
0.21.0+official
Code of Conduct
- [x] I agree to follow Elvish's Code of Conduct.
I did some searching in the codebase for calls to user.Current(). I see this occurring in two places:
pkg/edit/prompt.go:56: user, userErr := user.Current()
This is for deciding the default right prompt. Now I could override this in the config, but the default value will always be constructed, if my understanding of the code is correct. I think it should not be a problem to refactor that and only fetch the default value if there is no configured value.
pkg/fsutil/gethome.go:33: u, err = user.Current()
I think this can be avoided by testing for USERPROFILE on windows, instead of HOME, which is *nix.
This issue is almost not noticable with the elvish.exe binary built from source. The delay is about 3 seconds in that case, with subsequent spawns being instant again. Perhaps calls to user.Current() from the downloaded binary (using the powershell snippet on the website) may be under higher scrutiny by Anti Virus or firewall software?