Discovering Python interpreters takes a long time
See original GitHub issueType: Bug
Behaviour
Expected vs. Actual
- Launch VS Code insiders after an update
- The “Discovering Python Interpreters” step takes a very long time (I didn’t time it), so I don’t see my Python environments in the Jupyter kernel picker for a while
- Close VS Code insiders
- Launch VS Code insiders again (no update this time)
- The “Discovering Python Interpreters” step also takes a very long time (~40 seconds for that operation alone), but since Python environments were already loaded from previous session, they still do show up in the Jupyter kernel picker
Diagnostic data
- Python version (& distribution if applicable, e.g. Anaconda): 3.8.5
- Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Conda
- Value of the
python.languageServer
setting: Default
Output for Python
in the Output
panel (View
→Output
, change the drop-down the upper-right of the Output
panel to Python
)
XXX
User Settings
languageServer: "Pylance"
Extension version: 2022.13.12212101 VS Code version: Code - Insiders 1.71.0-insider (dced70bbf36d3c53c08e791da1791ac7fc42519b, 2022-08-10T05:17:53.560Z) OS version: Windows_NT x64 10.0.22000 Modes: Sandboxed: Yes
System Info
Item | Value |
---|---|
CPUs | Intel® Core™ i7-1065G7 CPU @ 1.30GHz (8 x 1498) |
GPU Status | 2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off |
Load (avg) | undefined |
Memory (System) | 15.60GB (1.34GB free) |
Process Argv | –crash-reporter-id 7c55b80b-a2c8-4229-8934-3646319b9311 |
Screen Reader | no |
VM | 0% |
A/B Experiments
vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
pythonvspyt551cf:30291413
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805:30301674
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30404738
wslgetstarted:30449409
cppdebug:30492333
pylanb8912:30522163
vsclangdf:30492506
c4g48928:30535728
dsvsc012:30540213
Issue Analytics
- State:
- Created a year ago
- Comments:11
Top Results From Across the Web
Windows: Discovering Python Interpreters takes forever · Issue ...
This is 100% reproducible. I've waited up to 10 minutes but the 'Discovering Python Interpreters' spinner is still spinning. For reference, this ...
Read more >"Discovering Python Interpreters" taking Infinite time in VS Code
The workaround I found is to terminate and restart VS Code until it discovers the Python interpreter in the virtual environment.
Read more >Python interpreter too slow - Visual Studio Feedback
REPL programming in python using the ipython interpreter is so slow that it can't be used. Typing something requires you to wait for...
Read more >Interpreter Discovery - Ansible Documentation
Unless configured otherwise, Ansible will attempt to discover a suitable Python interpreter on each target host the first time a Python module is...
Read more >Change the python interpreter discovery mode. - OpenDev
Current default mode for the python interpreter discover inansible 2.8 is auto_legacy. This patch changes the mode to auto, the biggest difference ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks for the explanation, however I am aware of this (my comment was a question based on some assumptions, hence prefixed with
if
). I’ve suggested using workers in the past to over come such blocking scenarios, I thought the plan was to implement such a technique, at least thats what I was informed when I demoed some perf improvements in the past https://github.com/microsoft/vscode-python/issues/15813Closing in favor of https://github.com/microsoft/vscode-python/issues/15813 where Jupyter adopts the Python API.