Новые среды разработки в цифрах: тесты скорости и памяти

Zed 1.0 потребляет примерно в 16 раз меньше памяти, чем VS Code. Холодный запуск занимает 0,12 секунды вместо 1,2, задержка ввода — 2 мс против 25.

На графике такое преимущество выглядит почти неприлично большим. В повседневной работе оно проявляется менее эффектно, но заметнее: ноутбук дольше не включает вентилятор, окно открывается без паузы, курсор не отстаёт от пальцев, а переключение между проектами не превращается в короткое ожидание. При этом низкое потребление ресурсов само по себе не делает среду полноценной заменой привычной IDE.

Релиз Zed 1.0 состоялся 29 апреля 2026 года. JetBrains Fleet вышел ранее, но продолжает позиционироваться как «лёгкая альтернатива». Обе среды претендуют на смену парадигмы — переход от тяжёлых Electron-приложений к нативным решениям. Цифры говорят сами за себя. Но цифры нужно уметь читать: часть разницы объясняется архитектурой, а часть — тем, какие функции среда запускает и от каких рабочих процессов отказывается.

Архитектурный сдвиг: почему Zed и Fleet меняют правила игры

VS Code построен на Electron — обёртке, которая запускает полноценный браузерный движок Chromium для рендеринга интерфейса. Это обеспечивает кроссплатформенность и богатую экосистему расширений. Цена — ресурсоёмкость. Отдельное окно, вкладки, фоновые задачи, анализ проекта и расширения работают внутри общей многопроцессной модели, где браузерный runtime становится базовым слоем для всего приложения.

Важно не упрощать эту картину до формулы «каждая функция — отдельный процесс». В VS Code расширения обычно выполняются в общих процессах extension host, а не получают по отдельному процессу каждое. Но сам extension host, языковые серверы, средства отладки, терминалы и другие компоненты могут добавлять собственную нагрузку. Чем сложнее рабочее окружение, тем больше фоновой работы и тем выше итоговое потребление памяти.

Это архитектурная плата за универсальность. Electron позволяет быстро доставлять одинаковый интерфейс на разные платформы, использовать веб-технологии и строить огромную систему расширений. Разработчик получает почти бесконечно настраиваемую среду, но расплачивается ресурсами компьютера. На мощной рабочей станции это может оставаться незаметным. На ноутбуке с ограниченной памятью или при параллельном запуске нескольких сервисов — уже нет.

Zed построен на Rust. Интерфейс рендерится напрямую через видеокарту с помощью собственного фреймворка GPUI. Между кодом и пикселями меньше промежуточных слоёв: среде не требуется содержать браузерный движок и обслуживать DOM-структуру интерфейса. Это не магическое ускорение каждой операции, а другой набор базовых решений.

Отсюда — высокая отзывчивость интерфейса и низкая нагрузка в простых сценариях. Zed не пытается воспроизвести всю модель VS Code с её исторически сложившимися слоями совместимости. Он выигрывает там, где важны быстрый рендеринг, короткий путь от ввода до отображения и небольшой объём фоновой работы.

JetBrains Fleet выбрал гибридный путь. У него два режима работы: Editor Mode без фонового языкового движка и Smart Mode с полноценным анализом кода. В Editor Mode среда ведёт себя как продвинутый текстовый редактор. В Smart Mode — как полноценная IDE с рефакторингом, навигацией, подсказками и более глубоким пониманием проекта.

Эта модель честнее, чем попытка постоянно называть Fleet лёгкой IDE. Лёгкость здесь зависит от режима. Если нужен быстрый просмотр файла или небольшая правка, Editor Mode действительно снижает нагрузку. Если включить Smart Mode для полноценной работы с большим проектом, среда начинает выполнять тот же класс задач, что и тяжёлые IDE, а вместе с ними возвращается и значительная часть потребления ресурсов.

Нативная архитектура не ускоряет всё подряд. Она убирает часть обязательных расходов, которые в Electron-среде возникают ещё до того, как разработчик начинает работать с кодом.

Скорость холодного запуска и работа с монорепозиториями

Холодный запуск — первый индикатор архитектурной эффективности. Zed 1.0 стартует за 0,12 секунды, VS Code — за 1,2 секунды. Десятикратная разница. На практике это ощущается не как абстрактное преимущество в бенчмарке: открыть файл, быстро проверить фрагмент кода или вернуться к проекту после короткого перерыва действительно получается без привычной паузы.

Но время запуска нельзя воспринимать как универсальный показатель производительности. Запущенная среда может открываться быстро, а затем долго индексировать проект, ждать языковой сервер или строить внутреннее представление файловой структуры. Поэтому холодный старт нужно рассматривать вместе со временем открытия проекта и готовностью функций анализа.

При открытии крупного монорепозитория на Java объёмом 100 000 строк расклад выглядит так:

Cursor, построенный на базе VS Code с добавлением AI-функций, показывает промежуточный результат — 4,5 секунды. VS Code загружает тот же сценарий за 6 секунд. Разница между Zed и VS Code составляет почти восемь раз.

В таком тесте важна не только скорость открытия окна. Монорепозиторий создаёт для IDE несколько параллельных задач: нужно пройти по дереву файлов, определить границы проекта, подготовить индексацию, активировать инструменты языка и отобразить рабочее состояние. Чем больше фоновых компонентов стартует одновременно, тем сильнее задержка между появлением окна и моментом, когда среда действительно готова принимать команды.

Zed не загружает runtime Electron, не инициализирует браузерный движок и не разбирает дерево DOM. Он быстрее переходит к парсингу файловой структуры и рендерингу. В этом смысле преимущество возникает не из-за одной удачно оптимизированной функции, а из-за отсутствия целого набора обязательных этапов.

Есть и обратная сторона. Быстро открыть проект — не значит получить полный набор возможностей для его анализа. Если разработчику нужны сложные рефакторинги, глубокая навигация по зависимостям, специфические языковые серверы или автоматизация через привычные расширения, часть выигранного времени может уйти на настройку альтернативного рабочего процесса. Для небольшого проекта это почти несущественно. Для большого командного монорепозитория — уже фактор миграции.

Потребление оперативной памяти: от 222 МБ до 3,5 ГБ

Цифры потребления оперативной памяти — наиболее показательный индикатор различий между подходами. В тесте с чистыми установками Zed использовал 222 МБ и пять процессов, тогда как VS Code занял 3549 МБ и запустил 23 процесса.

VS Code в этом сценарии расходует около 3,5 ГБ оперативной памяти при открытом проекте в режиме ожидания. Без активной компиляции, запущенных тестов и заметной работы линтеров это выглядит как базовый уровень нагрузки. Однако число процессов само по себе не объясняет весь расход: важны их назначение, объём загруженных библиотек, состояние индексации и состав расширений.

Расширения VS Code обычно работают в общих процессах extension host. Поэтому некорректно говорить, что каждое расширение добавляет собственный процесс. Точнее будет сказать так: расширения увеличивают нагрузку на extension host и могут запускать или активировать дополнительные компоненты — например, языковые серверы, отладчики, индексаторы и вспомогательные службы. В результате растёт не обязательно число процессов один к одному, а совокупное потребление памяти и фоновой активности.

222 МБ против 3549 МБ — разница в 16 раз. Но это прежде всего разница между двумя наборами встроенных возможностей и фоновых служб, а не универсальный коэффициент для любой конфигурации.

JetBrains Fleet, несмотря на позиционирование лёгкой альтернативы, потребляет более 2 ГБ оперативной памяти при открытии проекта. Размер дистрибутива — около 2 ГБ бинарных файлов и библиотек. Для сравнения: размер установщика VS Code — порядка 90 МБ. Fleet тяжелее VS Code в двадцать раз на диске и заметно тяжелее Zed в памяти.

Сравнение размера установщика и потребления оперативной памяти показывает разные характеристики. Диск хранит библиотеки, кэш, ресурсы и компоненты, которые не обязательно загружены в память одновременно. Оперативная память отражает текущее состояние приложения: открытый проект, индексы, фоновые процессы и активный режим работы. Поэтому большой дистрибутив не означает автоматически такое же увеличение RAM, а маленький установщик не гарантирует экономную работу после запуска.

Приведённые данные получены на чистых установках без расширений. В реальной эксплуатации VS Code с набором из 20–30 плагинов может потреблять ещё больше. При этом итоговая нагрузка зависит от самих плагинов: простой инструмент оформления кода и языковой сервер с индексированием большого проекта — неравноценные потребители ресурсов.

Zed на момент релиза 1.0 располагает ограниченным каталогом расширений, поэтому сравнение на равных условиях с идентичным набором плагинов пока невозможно провести корректно. Его низкий результат частично объясняется тем, что среда выполняет меньше фоновой работы и предлагает меньше подключаемых компонентов. Это не отменяет архитектурного преимущества, но меняет интерпретацию теста: сравниваются не только движки, но и фактический объём задач.

Для разработчика важен не рекорд минимального потребления, а запас памяти в рабочем сценарии. Если одновременно открыты IDE, браузер с документацией, локальная база данных, контейнеры и несколько сервисов, разница между 222 МБ и несколькими гигабайтами становится практической. Среда, которая занимает меньше памяти, оставляет больше ресурсов компилятору, виртуальной машине и инструментам проекта.

Энергоэффективность и задержка ввода: влияние на комфорт разработки

Тридцатиминутный тест с использованием утилиты macOS Powermetrics показал следующие результаты накопленной мощности:

VS Code потребляет в 2,58 раза больше энергии, GoLand — в 6,18 раза больше. Для ноутбука это связано не только с автономностью. Высокая фоновая нагрузка означает больше тепла, более активную работу системы охлаждения и потенциальное снижение частот процессора под длительной нагрузкой.

При этом нельзя буквально переносить тридцатиминутный показатель на весь рабочий день. Энергопотребление меняется в зависимости от размера проекта, активности индексации, запуска тестов, состояния батареи и подключённых устройств. Разница в тесте показывает направление, а не обещает одинаковую экономию в каждом сценарии. В простом редактировании Zed может сохранять преимущество, но при тяжёлой задаче решающими становятся уже компилятор, контейнеры и локальные сервисы.

Задержка ввода — время между нажатием клавиши и появлением символа на экране:

• Zed: 2 мс, в отдельных тестах — до 10 мс;
• VS Code: 25 мс.

Разница в 12,5 раза. Порог восприятия человеком находится примерно на уровне 50 мс, ниже которого операция обычно воспринимается как мгновенная. Обе среды укладываются в этот порог, но при быстром наборе кода разница между 2 и 25 мс становится заметной. Особенно если параллельно работают анализатор, сборка, браузер с тяжёлыми вкладками или виртуальная машина.

Здесь важно разделять субъективный комфорт и измеримую задержку. Разработчик может не назвать 25 мс «лагом», но почувствовать, что интерфейс стал менее плотным и прямым: курсор реагирует чуть позже, прокрутка иногда догоняет жест, подсказки появляются с дополнительной паузой. В течение нескольких минут это не мешает. За много часов работы такие мелкие задержки складываются в ощущение тяжёлой среды.

Причина снова связана с архитектурой. Zed рендерит каждый кадр через GPUI на GPU. VS Code проходит через слой Electron, который добавляет промежуточные этапы при обработке событий ввода и перерисовке интерфейса. Это не делает Electron непригодным для разработки: его модель обеспечивает расширяемость и переносимость. Но при прямом сравнении отзывчивости нативная среда получает преимущество за счёт более короткого пути от события до отображения.

На слабом оборудовании разница заметнее, потому что у системы меньше свободного ресурса для компенсации фоновой работы. На мощной станции задержка может практически исчезать. Поэтому тесты скорости ввода и энергопотребления особенно полезны на том устройстве, на котором предстоит работать, а не на условной лабораторной конфигурации.

Режимы работы и ограничения: когда стоит переходить на новые IDE

Переход на новую среду разработки — это не только выигрыш в цифрах. Это компромисс между производительностью интерфейса, возможностями анализа и совместимостью с рабочим процессом. У каждой среды есть ограничения, которые лучше обнаружить до миграции, а не после отказа от привычного инструментария.

Zed 1.0

Zed даёт максимальную производительность в сценариях, где важны скорость отклика и низкое потребление ресурсов. Он особенно убедителен при локальной работе с кодом, быстрых правках, навигации по относительно простым проектам и использовании ноутбука с ограниченным запасом памяти.

Ограничения на момент релиза следующие:

• экосистема расширений заметно меньше, чем у VS Code;
• удалённая разработка через SSH поддерживается ограниченно и не является полноценной заменой зрелому сценарию VS Code Remote SSH;
• совместимость со сложными цепочками плагинов VS Code неполная;
• macOS и Linux поддерживаются, Windows находится на стадии разработки.

Последний пункт важен не только для выбора операционной системы. Если команда работает на разных платформах, среда должна одинаково вписываться в локальные соглашения, настройки форматирования, запуск задач и отладку. Преимущество Zed на одном ноутбуке не компенсирует проблемы с воспроизводимостью процесса у остальных участников.

Ограниченная поддержка SSH также не означает полного отсутствия удалённой работы. Она означает, что привычный сценарий подключения к удалённой машине, установки инструментов и работы с проектом может быть доступен не во всех вариантах или иметь функциональные ограничения. Для команды, которая ежедневно разрабатывает внутри удалённых окружений, это нужно проверять на конкретной инфраструктуре.

Zed оптимален для разработчиков, которым критичны скорость отклика и энергоэффективность и которые работают с локальными проектами без зависимости от богатого каталога плагинов. Он также подходит как второй инструмент: не обязательно сразу переносить в него весь рабочий процесс. Иногда достаточно использовать его для быстрых правок, чтения кода и небольших задач, сохранив основную IDE для сложных операций.

JetBrains Fleet

Fleet делит среду на два инструмента, не маскируя разницу между ними:

• Editor Mode — быстрый редактор без фонового анализа кода; потребление ресурсов ниже, функциональность ограничена;
• Smart Mode — полноценная IDE с рефакторингом, навигацией по коду и автодополнением; потребление ресурсов заметно возрастает.

Эта схема удобна для проектов, где большую часть времени нужно читать и изменять файлы, но иногда требуется глубокое понимание кода. Неудобство появляется в тот момент, когда Smart Mode приходится держать включённым постоянно. Тогда главный аргумент Fleet — лёгкость — теряет силу, а по ресурсоёмкости среда приближается к полновесным IDE.

Fleet целесообразен для команд, уже использующих экосистему JetBrains. Им проще принять режимы работы и сохранить привычную модель анализа кода, чем полностью перестраивать инструментарий под другую платформу. Для нового проекта выбор зависит от того, что важнее: быстрый Editor Mode или функциональность Smart Mode без переключения на отдельную тяжёлую IDE.

VS Code

VS Code остаётся референсом по универсальности. Его преимущества — самый большой каталог расширений, активное сообщество, кроссплатформенность и зрелая поддержка удалённых сценариев через SSH, Containers и WSL. Большинство команд выбирает его не потому, что он минимально потребляет память, а потому, что под конкретный стек уже существует готовая связка инструментов.

Архитектурные ограничения — плата за эту универсальность. VS Code приходится обслуживать не только редактор и файлы, но и слой совместимости, расширения, языковые сервисы, терминалы, отладчики и интеграции. В результате среда может быть тяжелее нативных альтернатив, зато переход от одного проекта к другому требует меньше компромиссов.

Что проверить на реальном проекте

Выбор новой IDE лучше начинать не с абстрактного рейтинга, а с инвентаризации собственного рабочего процесса. Сначала стоит выписать расширения VS Code, которые используются ежедневно, и разделить их на действительно критичные и просто привычные. Для каждого критичного инструмента нужно найти замену в каталоге Zed, проверить работу в Fleet или определить, можно ли выполнить задачу средствами самого проекта.

Отдельно нужно проверить удалённую разработку, контейнеры и WSL. Если исходный код находится на сервере, а локальная машина используется только как интерфейс, ограниченная поддержка SSH в Zed может стать не запретом на миграцию, а серьёзным условием миграции. Здесь важен не сам факт подключения, а полнота сценария: установка зависимостей, доступ к терминалу, работа языковых серверов, отладка и сохранение настроек.

Тестировать среду нужно на настоящем проекте, а не на hello-world. Минимальный практический сценарий включает:

1. открыть рабочий монорепозиторий и дождаться завершения первоначальной индексации;

2. проверить навигацию, автодополнение, поиск по проекту и переход к определениям;

3. выполнить обычную сборку, запустить тесты и открыть терминал;

4. измерить потребление памяти в режиме ожидания и во время фоновой активности;

5. оценить задержку ввода на целевом оборудовании, особенно при открытом браузере и локальных сервисах;

6. повторить тест в Editor Mode и Smart Mode, если речь идёт о Fleet;

7. проверить, как среда ведёт себя после перезапуска и восстановления рабочего состояния.

Синтетические бенчмарки полезны для сравнения архитектур, но не заменяют профилирование на рабочей нагрузке. В одном проекте решающим окажется время загрузки, в другом — скорость индексирования, в третьем — стабильность удалённого подключения. Низкое потребление памяти в режиме ожидания не гарантирует такого же результата во время компиляции или анализа большого количества зависимостей.

На ноутбуках имеет смысл отдельно провести замер энергопотребления через Powermetrics на macOS или аналогичные инструменты на другой платформе. Сравнивать нужно одинаковый набор действий и одинаковое состояние проекта. Если в одной среде включён Smart Mode, а в другой открыто только несколько файлов, итоговые цифры будут говорить скорее о конфигурации теста, чем о качестве IDE.

Наконец, переход не обязан быть одномоментным. Конфигурацию VS Code — settings.json, список расширений и рабочие соглашения проекта — стоит сохранить до эксперимента. Первые две недели лучше использовать новую среду параллельно и фиксировать конкретные проблемы: падения, неработающие расширения, задержки индексации, сложности с удалённым доступом и ситуации, в которых приходится возвращаться в старый редактор. Такой журнал даёт больше информации, чем общее впечатление после первого запуска.

Производительность новых IDE — это не только цифра в тесте

Тесты сред разработки убедительно показывают преимущество нативного подхода в базовых сценариях. Zed быстрее запускается, экономнее расходует память и демонстрирует меньшую задержку ввода. Fleet предлагает компромисс между редактором и полноценной IDE через разные режимы работы. VS Code сохраняет лидерство там, где важны расширения, совместимость и удалённая инфраструктура.

Поэтому вопрос о переходе нельзя формулировать как «какая среда быстрее». Корректнее спросить, какую часть своей работы разработчик готов отдать более лёгкому инструменту. Если основная нагрузка — локальное редактирование, чтение кода и быстрые изменения, разница между 222 МБ и 3,5 ГБ становится весомым аргументом. Если процесс завязан на десятки расширений, SSH, контейнеры, WSL и сложные языковые сервисы, универсальность VS Code может оказаться важнее архитектурной экономии.

Переход на новые среды разработки — не хайп и не дань моде. Это техническое решение с измеримыми параметрами. Цифры говорят в пользу нативных решений, но цифры на бенчмарке и цифры в продакшене — разные данные. Оценивать нужно на своём стеке, со своими расширениями, в нужном режиме и на своём оборудовании. Всё остальное — экстраполяция с погрешностью.