Проверка зависимостей в сборках может стать в 54 раза быстрее: исследователи из Университета Васэда показали инструмент mkcheck2, который снижает накладные расходы на поиск ошибок до 99,7% по сравнению с ptrace-подходами. Для команд, где CI и так уже трещит под нагрузкой от частых коммитов, автогенерации кода и многоступенчатых пайплайнов, это не академическая мелочь, а потенциальная экономия часов машинного времени.
О работе Юты Сайто, Кадзунори Сакамото и Хиронори Васидзаки сообщает The Register. Исследователи описали подход в статье «Efficient Build Dependency Verification Using eBPF and Incremental Analysis», опубликованной в материалах конференции ICSE 2026. Они разработали mkcheck2 — инструмент для обнаружения ошибок в спецификациях зависимостей сборки, который использует трассировку системных вызовов через eBPF и инкрементальный анализ.
Проблема знакома любому, кто жил рядом с Makefile, CMake-проектом или более современными системами сборки. Сборщик должен понимать, какие исходники, заголовки, сгенерированные файлы, артефакты и тесты от чего зависят. Если зависимость описана неправильно, проект может собраться «успешно», но не пересобрать нужный файл после изменения. Или наоборот — пересобирать слишком много, превращая каждую мелкую правку в кофе-брейк с элементами отчаяния.
По данным авторов исследования, управление спецификациями зависимостей отвечает более чем за половину ошибок сборки в крупных проектах. Это болезненная зона: баги здесь не всегда проявляются сразу, плохо воспроизводятся и часто всплывают уже после того, как разработчик уверен, что «у меня всё собралось». Поэтому инструменты, которые проверяют реальные обращения процесса сборки к файлам и сравнивают их с объявленными зависимостями, полезны, но у них есть цена.
Традиционные решения часто опираются на ptrace. Этот механизм позволяет наблюдать за системными вызовами процесса, но делает это тяжеловесно: процесс приходится приостанавливать, переключаться между контекстами и обрабатывать каждое событие с заметным влиянием на производительность. Для разовой диагностики это терпимо. Для постоянной проверки в каждом коммите — уже сомнительное удовольствие, особенно в больших репозиториях.
mkcheck2 переносит наблюдение ближе к ядру Linux. eBPF позволяет запускать изолированные программы в пространстве ядра и собирать низкоуровневые события без такого количества остановок и переключений. В контексте сборки это означает, что инструмент может отслеживать файловые обращения и другие системные вызовы с меньшим вмешательством в сам процесс. Исследователи формулируют идею просто: трассировка должна быть достаточно дешёвой, чтобы её можно было включать не только во время пожара.
Цифры у работы бодрые. На корпусе из 300 open source-проектов с Make инкрементальный анализ снизил среднее время анализа на коммит с 1267,49 секунды до 23,56 секунды. Это и даёт примерно 54-кратное ускорение. В сравнении с ptrace-подходами накладные расходы на обнаружение ошибок зависимостей сокращались до 99,7%, при этом авторы заявляют сохранение точности обнаружения.
Для разработчиков главный смысл не в красивой кратности, а в смене режима использования. Если проверка зависимостей занимает двадцать минут, её будут запускать выборочно: перед релизом, после крупных изменений, когда уже что-то сломалось. Если она укладывается в десятки секунд, её можно поставить ближе к обычному CI и ловить ошибки там, где они дешевле всего — рядом с коммитом, а не через неделю в загадочном падении nightly-сборки.
Для бизнеса это история про менее заметную, но дорогую часть инженерной инфраструктуры. Быстрые сборки обычно обсуждают через кэширование, распределённые компиляторы и оптимизацию пайплайнов. Но неверные зависимости бьют по доверию к самой системе сборки: команда начинает вручную чистить артефакты, перезапускать задачи, добавлять лишние зависимости «на всякий случай». Так технический долг просачивается в каждый рабочий день, тихо съедая производительность.
Есть и ограничения, о которых важно не забыть. Подход завязан на eBPF, а значит, его преимущества в первую очередь относятся к Linux. Для macOS, Windows и других окружений такой выигрыш напрямую не переносится. Авторы также называют сложные случаи: некоторые избыточные зависимости, доступ к memory-mapped-регионам, динамически загружаемые библиотеки, сетевые зависимости и распределённые системы сборки. Иными словами, mkcheck2 не превращает хаотичный build-файл в идеальную инженерную поэму одним запуском.
Контекст тоже важен. Генеративные инструменты уже ускорили написание кода, но не отменили физику сборок, тестов и инфраструктуры. Чем быстрее команды производят изменения, тем сильнее давление на системы валидации: они должны быть не просто точными, а достаточно дешёвыми для постоянного применения. Проверка зависимостей через eBPF хорошо ложится в этот тренд: перенос наблюдаемости на более низкий уровень даёт шанс убрать часть трения без переписывания всей сборочной экосистемы.
Пока mkcheck2 выглядит скорее как исследовательский инструмент с практическим потенциалом, чем как новая обязательная кнопка в каждом CI. Но направление понятно: сборочные системы будут всё чаще проверять не только результат, но и собственную честность — какие файлы реально читались, что было объявлено зависимостью, где пайплайн врёт сам себе. Подробности исследования и исходные цифры приведены в материале ; следующий вопрос для индустрии — кто первым упакует такую проверку в удобный инструмент, который не потребует от команды отдельного специалиста по ядру Linux.