IDE тормозит: кэш, версия, portable-папка, первый запуск и индексация

После переустановки системы Blink у меня собирался минуту с лишним, а ESP32-проект на тот же стол выдавал четверть часа на каждую сборку. Первая мысль была «среда окончательно раздулась», вторая — «железо состарилось». Обе оказались ложными: виноват был антивирус, сканировавший каждую мелкую запись в temp, и холодный кэш после чистки. Три исключения в настройках защитника вернули секундные сборки без единого апгрейда, и с тех пор я чиню «тормозящую среду» по списку, а не по настроению. Диагноз занял вечер, лечение — десять минут и три строки в настройках защитника.

Числа для калибровки. Холодная сборка свежего ядра — около минуты даже для Blink: компилятору нужно пересобрать всё ядро. Тёплая — единицы секунд, потому что объектные файлы переиспользуются из кэша. На страницах обсуждений среды фигурируют жалобы и страшнее: десять минут на маленькую программу — классический случай антивирусного скана на запись, и по пятнадцать минут на ESP32-проекты, когда сканер проверяет каждый объектник. Норма — секунды на тёплую сборку; всё, что дольше минуты на маленьком скетче, — диагноз, а не судьба. Разница между «поломалось» и «кэш остыл» — первое число, которое я теперь смотрю в любом разговоре про медленную среду.

Адреса, где живёт хозяйство. Сборки копятся в системной temp — на Windows это папки с именами arduino-sketch- и набором символов в %TEMP%; пакеты плат, инструменты и скачанные индексы — в скрытом каталоге Arduino15 в профиле, на Windows %LOCALAPPDATA%\Arduino15. Каждая платформа весит от сотен мегабайт, пакет ESP32 с инструментами переваливает за гигабайт. Скетчбук при этом отдельно — структура папок скетча его описывает; тормоза же сидят в temp и Arduino15, а не в скетчах.

Разбор по слоям: первый запуск и индексы, кэш сборки и его очистка, антивирус, вес платформ, версия среды — и в конце переносимость, потому что portable-папка решает не только «на флешку», но и «быстрее стартует».

Свежая установка второй среды при первом запуске скачивает и обновляет индексы плат — окна статуса висят со строками про updating index, списки плат пустые или серые. На медленном канале это минуты, и выглядит как зависание. Правило простое: дождаться. Индексы — маленькие json-каталоги, но без них менеджер плат не покажет список, а среда будет повторять попытку при каждом старте. Сорвать установку на середине — значит получить те же минуты, но каждый раз. Список плат в Tools при этом может оставаться серым до конца индексации — это очередь, а не сбой.

Каждая установленная платформа — не только мегабайты на диске, но и строка в индексах: список плат в Tools заполняется дольше, обновление каталога при старте — дольше, поиск по меню — дольше. Четыре ядра, из которых живёт одно, — типовая находка при разборе тормозов. Лечится удалением неиспользуемых платформ из карточки менеджера плат — механика карточек и package-ссылок разобрана в уроке про Boards Manager и package URL. Один гигабайт ESP32-пакета, который нужен раз в квартал, стоит ставить перед работой и снимать после — жёсткий диск скажет спасибо.

Посмотреть руками на всё это хозяйство стоит один раз, чтобы перестать его бояться: в temp лежат папки arduino-sketch- с цифрами, в Arduino15 — подпапки packages и staging, где живут ядра и скачанные архивы. Я показываю это новичкам на втором занятии: увиденные сотни мегабайт перестают быть «мусором, который надо чистить», и исчезает главный источник самосаботажа — ручная чистка всего подряд с последующим «почему стало только хуже».

Кэш сборки — второй слой. Тёплая сборка в секунды существует, пока жива папка arduino-sketch- в temp: компилятор подхватывает готовые объектники ядра. Чистить temp руками не нужно — система съест её при нехватке места сама, и тогда одна сборка снова станет холодной на минуту. Проблема другого рода — побитый кэш: после отключения питания посреди сборки или чистки защитником файлы в temp оказываются кривыми, и сборка падает странно и невоспроизводимо. Для этого случая свежие версии второй среды получили явный пункт очистки сборки, а в терминале то же делает флаг --clean у arduino-cli — команды собраны в уроке про CLI-компиляцию.

Версия среды — слой, который забывают. Бетарелизы второй линейки тормозили заметно сильнее финальных, и часть «среда стала хуже» в обсуждениях 2022 года лечится простым обновлением до финальной 2.3.x: правки скорости туда вносили волнами. Проверка стоит минуты: Help → About, и сравнение с последним релизом на странице проекта.

Сборка — это тысячи мелких записей в temp за короткое время, и защитник Windows по умолчанию проверяет каждую. На записи объектников, копировании инструментов и запуске avr-gcc время умножается на несколько — отсюда десяти- и пятнадцатиминутные сборки из жалоб. Лечение — не отключение защиты, а исключения папок в настройках антивируса: системная temp, каталог Arduino15 и папка с вашими скетчами. После исключений цифры возвращаются к таблице норм: секунды тёплая, до минуты холодная. Исключения ставьте точечные: три папки, а не весь диск — защитник остаётся сторожем для всего остального, и безопасность не платит за скорость. Тот же приём работает для сторонних антивирусов — список исключений у них называется так же.

Память — второй ресурс. Редактор второй линейки держит сотни мегабайт, монитор с плоттером добавляют, браузер добавляет ещё; на машине с 4 ГБ всё это складывается в ощутимые тормоза интерфейса, которые легко перепутать с медленной сборкой. Отличить просто: сборка идёт в статусной строке и занимает процессор — это минуты в логе; тормозит интерфейс — это прокрутка и ввод. Если второе, закрывайте лишнее или перечитайте урок про сравнение линеек: на слабом железе линейка 1.8 остаётся легальным ответом.

Полезно следить за одним числом: время тёплой сборки вашего самого частого скетча. Запишите его после первого тёплого прогона рядом с версией среды — у меня это четыре секунды на Blink в 2.3.x. Число выросло вдвое без видимых причин — значит, что-то изменилось в окружении, и пять шагов диагностики ниже начинаются не с догадок, а со сравнения с эталоном. Это самая дешёвая метрика в теме: её снимает одна повторная сборка, и врать она не умеет.

Переносимость в теме скорости звучит неожиданно, но связка прямая: переносная копия со своими каталогами не тащит на старте пересчёт чужих индексов, а CLI-сборка вообще не поднимает редактор. Полный разбор portable.txt у 1.8, ZIP-сборки 2.x и каталогов конфига у CLI — в уроке про переносную среду и версии; здесь напомню только вывод: чем меньше слоёв запускается перед компилятором, тем предсказуемее секунды.

Мой порядок диагностики на живой машине — пять шагов, сверху вниз: посмотреть, холодная ли сборка (первая после чистки temp — это норма); проверить исключения антивируса для temp, Arduino15 и папки скетчей; посчитать платформы в менеджере и снять неиспользуемые; сверить версию среды с последней финальной; и только потом смотреть память и фоновые программы. За пять минут список отсекает девять из десяти случаев — дальше остаются действительно редкие, и они уже не «среда тормозит», а конкретный проект с конкретной библиотекой. Если же первые четыре шага чисты, виноват обычно код: мегабайтные массивы в памяти, десятки Serial.print в цикле, плоттер на три серии — это лечится в скетче, а не в настройках среды.

И про альтернативу как предохранитель: если редактор нужен только для правки текста, а сборки идут на автомате, конвейер переезжает в терминал целиком, а вместо IDE остаётся любой редактор — механику и цену такого переезда считал в уроке про PlatformIO против Arduino IDE. Для большинства же ответ банален: тёплый кэш, три исключения в защитнике и честная финальная версия возвращают среду к табличным секундам — на моём ноутбуке это произошло между обедом и ужином, без единого рубля. За полгода с тех пор список вспоминался дважды — оба раза виноват был антивирус после обновления, вернувшийся к скану temp с заводскими настройками.