Background

• Kernel push currently doesn't show run button until a controller is available for the notebook
• 90% of users experience kernel search time taking 5 seconds or less
• Our goal is to allow notebooks to load ASAP and allow users to run code ASAP
• Listing interpreters is the slow part of kernel search at the moment

Ideas for making first-time controller search as fast as possible

• Generate a dummy preferred controller and hotswap it out for the real preferred kernel when the user attempts to execute code
  • If we can't find a kernel that matches what the notebook metadata says, we should ask the user if the one we found instead is OK. Classic Jupyter doesn't prompt--it picks randomly
  • If Python extension has an active interpreter and notebook metadata only says 'Python 3', use that one
  • Scenario: notebook metadata says 'Python 3' --> when we find an interpreter e.g. Python 3.9, the kernel picker will change from 'Python 3' to 'Python 3.9'
  • We only put up our dummy kernel when there aren't any other extensions which might be able to provide a better kernel, e.g. we won't show our dummy kernel for .NET interactive notebook
• Generate a partial list of kernels vs doing a full search

For subsequent activation we can also cache interpreters/kernelspecs (we currently don't do any caching)

• However there are potential issues with when we invalidate the cache e.g. for users whose cache is months old

Other ideas

• Get Python extension to move all its interpreter discovery into an npm package
  • Assumption here is that Python extension activation is the bottleneck
    • But we need the active interpreter which relies on VS Code settings so npm package might not work either