VS Code Extension Host грузит CPU: как найти проблемное расширение

Почему Extension Host может грузить CPU отдельно от интерфейса

Архитектура VS Code специально отделяет расширения от основного интерфейса: extension host запускает их код в отдельном процессе, чтобы код расширений выполнялся отдельно от основного renderer-процесса. Но расширение всё равно может постоянно индексировать файлы, реагировать на события файловой системы, выполнять линтинг, строить подсказки или зациклиться на ошибке. Поэтому в системном мониторинге вы можете видеть нагрузку у процесса, связанного с extension host, даже если само окно редактора не выглядит зависшим. Первая задача — доказать связь с расширениями. Официальный CLI позволяет открыть проект с `code --disable-extensions .`; то же можно сделать командой Disable All Installed Extensions. Если CPU быстро возвращается к норме, не меняйте настройки проекта вслепую: это сильный признак проблемы расширения или его взаимодействия с конкретным workspace. Если нагрузка остаётся и без расширений, переходите к диагностике самого редактора, Git, файловой системы или огромного проекта.

Совет: Перед тестом запишите, при каком действии начинается нагрузка: сразу после открытия папки, после сохранения, запуска терминала, Git-операции или открытия конкретного файла.

Как локализовать расширение без перебора десятков плагинов

1. Откройте Help → Open Process Explorer и убедитесь, какой процесс держит CPU. Если это extension host, продолжайте диагностику расширений; если renderer/GPU/terminal — не обвиняйте плагины без проверки.
2. Запустите проект с отключёнными расширениями. Если высокий CPU исчез, подтвердите результат ещё раз обычным запуском.
3. Откройте Command Palette → Developer: Show Running Extensions. Посмотрите, какие расширения активны, и при необходимости запустите профилирование extension host.
4. Запустите Extension Bisect. VS Code будет выключать группы расширений и спрашивать, сохранилась ли проблема, постепенно уменьшая набор кандидатов.
5. Когда найден кандидат, отключите его только для текущего Workspace и перезапустите extension host. Это оставит расширение доступным в других проектах.
6. Проверьте Marketplace/репозиторий расширения на обновление и известные проблемы. Если баг воспроизводится на актуальной версии, подготовьте минимальный проект и отчёт через встроенный Issue Reporter.

Предупреждение: Extension Bisect требует честно отвечать, сохранилась ли проблема на каждом шаге. Ошибочный ответ легко приводит к ложному виновнику.

Как трактовать тест без расширений

• CPU нормальный без расширений. Высока вероятность стороннего extension-конфликта. Running Extensions + Extension Bisect
• CPU высокий даже без расширений. Причина может быть в core, Git, watcher, терминале или файлах. Сузить workspace и действие-триггер
• Проблема только в одном workspace. Триггер связан с проектом/настройками/объёмом файлов. Отключать расширение для Workspace и сокращать проект
• После обновления расширения начались лаги. Возможна регрессия версии. Зафиксировать версию и воспроизведение

Что проверить у «тяжёлого» проекта, прежде чем обвинять расширение

Расширение может быть корректным, но получать слишком много работы из-за структуры проекта. Типичный пример — монорепозиторий с гигантским build-каталогом, generated-файлами, vendor-зависимостями и непрерывно меняющимися логами. Если плагин реагирует на файловые события или анализирует каждый документ, нагрузка растёт пропорционально потоку изменений. Проверьте, можно ли исключить нерелевантные каталоги средствами самого расширения или настройками workspace, не скрывая при этом исходный код, который реально нужен для навигации. Отдельно посмотрите, начинается ли CPU после Git status на репозитории с тысячами изменений, после открытия терминала или только при конкретном языке. Создайте минимальную копию проекта без build/output каталогов и повторите сценарий. Такая проверка отличает баг расширения от чрезмерной рабочей нагрузки и позволяет написать разработчику полезный отчёт вместо фразы «VS Code тормозит».

Важно: Не добавляйте огромные системные папки в исключения наугад. Сначала определите, какой компонент действительно читает эти файлы.

Как оформить воспроизводимый отчёт о производительности

Для отчёта важнее последовательность действий, чем скриншот диспетчера задач. Укажите версию VS Code, ОС, идентификатор и версию расширения, тип проекта и момент, когда CPU начинает расти. Опишите контрольный тест: например, «с `--disable-extensions` нагрузка исчезает; с включённым расширением X возвращается после открытия файла Y». Если Running Extensions или профилировщик позволяют собрать данные, приложите их через предусмотренный канал расширения или Issue Reporter, не публикуя секреты проекта. Если расширение запускается в remote host, укажите Remote SSH/WSL/Dev Container, потому что место выполнения влияет на файловую систему и доступные ресурсы. После обновления или отката повторите тот же сценарий, не меняя одновременно пять настроек. Так можно уверенно сказать, исправилась ли проблема, и не оставить в конфигурации случайные «лечебные» исключения.

Совет: Если проблема исчезает после отключения одного расширения только в конкретном workspace, используйте Disable (Workspace), а не удаление глобально.

Как проверить, что нагрузка действительно ушла

После отключения подозрительного расширения не ограничивайтесь ощущением, что интерфейс стал плавнее. Повторите тот же сценарий: откройте тот же workspace, подождите завершения индексирования и выполните действие, после которого рос CPU. Затем включите расширение снова и сравните результат. Такая парная проверка защищает от ложного вывода, когда нагрузка исчезла просто потому, что закончилась фоновая индексация. Если проблема зависит от конкретного проекта, сохраните минимальный набор файлов и настроек, который её воспроизводит: разработчику расширения такой пример значительно полезнее общего описания «VS Code грузит процессор».

Признаки, что виновник найден

• Высокий CPU воспроизводится с одним и тем же расширением.
• Без него проблема исчезает при тех же файлах и действиях.
• Extension Bisect указывает на тот же кандидат.
• Повторное включение возвращает симптом.
• Есть понятный триггер: файл, save, Git, watcher, language service или команда расширения.

Что учитывать

Архитектура VS Code специально отделяет расширения от основного интерфейса: extension host запускает их код в отдельном процессе, чтобы код расширений выполнялся отдельно от основного renderer-процесса. Но расширение всё равно может постоянно индексировать файлы, реагировать на события файловой системы, выполнять линтинг, строить подсказки или зациклиться на ошибке. Поэтому в системном мониторинге вы можете видеть нагрузку у процесса, связанного с extension host, даже если само окно редактора…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Extension Host). Пример и формулировки — редакция N1RO на 2026-09-20.

• Extension Host
• Extension Marketplace
• Command Line Interface (CLI)
• April 2018 (version 1.23): Process Explorer