-
-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shell startup is slow due to VirtualFish completions #243
Comments
Many thanks for the detailed report, Anthony. It is rare and refreshing to see not only a detailed report, but also some concrete ideas and code regarding how the issue might be resolved. Bravo! As you accurately point out, VirtualFish completions rarely change, which makes me wonder whether we need to generate the completions (even in cached form) on every shell startup. Perhaps we could install the completions as part of the After reviewing where to put completions, perhaps they should go in Looking forward to your thoughts. Once again, much appreciated! |
Issue
I've been profiling my Fish shell startup time and have found the VirtualFish loading script to consume a significant chunk of time.
After doing some investigation, I've found it to be directly caused by the
__vfsupport_setup_autocomplete
function, specifically the part that extracts the help text from all the VF functions.Here's timing information with an without that specific function:
To further investigate, I've extracted that specific function to its own script and profiled it as follows (repeated parts reduced for clarity):
As you can see, the
for sc in (functions ...)
loop is taking the majority of the time (>100ms), and this is almost entirely attributed to every invokation of grep taking ~5ms.Possible Solutions
Since the completions don't often change, it might be better to generate them once and cache them. Here's a working example that can replace the
__vfsupport_setup_autocomplete
function in virtual.fish:This function takes ~120ms upon the first run, but subsequent runs take <2ms, representing a significant speedup!
The text was updated successfully, but these errors were encountered: