Understanding the process model explains performance problems, crashes and why the same language servers work in many editors.
VS Code is an Electron application: a main process manages windows, and each window's renderer draws the workbench (the UI). Extensions do not run in the renderer. They run in a separate Node.js extension host process, so a slow or crashing extension cannot freeze typing; at worst the host restarts. Remote and web scenarios add more hosts (remote, web worker).
Extensions are loaded lazily via activation events (opening a Python file, running a command, a workspaceContains pattern). Badly configured extensions that activate on * slow startup for everyone.
Two open protocols do much of the heavy lifting:
- The Language Server Protocol (LSP): a language server (often a separate process, such as Pyright, gopls or rust-analyzer) provides completion, diagnostics, go to definition and rename over JSON-RPC. The same servers power Neovim, Emacs and other editors.
- The Debug Adapter Protocol (DAP): a debug adapter translates VS Code's generic debugging UI to a specific runtime's debugger.
Diagnosing problems:
- "Developer: Show Running Extensions" lists activation times and flags unresponsive extensions.
- "Developer: Startup Performance" breaks down window load time.
code --disable-extensionsstarts clean; "Help: Start Extension Bisect" isolates a culprit.- "Developer: Open Process Explorer" shows CPU and memory per process, including language servers.
Example
# start without extensions to test a problem
code --disable-extensions .
# show where time goes during startup
code --prof-startup .
# Command Palette:
# Developer: Show Running Extensions activation time per extension
# Developer: Startup Performance window load breakdown
# Developer: Open Process Explorer CPU/memory per process
# Help: Start Extension Bisect binary-search a bad extension
# Output panel > "Python Language Server" / "TypeScript": LSP logsRemember
- Extensions run in an isolated extension host, not the UI process
- Activation events load extensions lazily
- LSP for language features, DAP for debuggers, shared with other editors
Watch out for
- Blaming VS Code for slowness that comes from one extension; check Running Extensions first.