Поки генеративні ШІ-агенти беруть на себе написання коду, японські дослідники вирішили прискорити інший етап розробки — перевірку залежностей під час збірки. Їхній новий метод дозволяє скоротити накладні витрати на пошук помилок у залежностях аж на 99,7%, пише The Register.

Чому залежності стають вузьким місцем

Такі системи збірки, як Make, CMake чи Zig build, відповідають за перетворення вихідного коду на готові програми. Вони визначають послідовність компіляції файлів і слідкують за коректним зв'язуванням об'єктних файлів між собою. Окрім цього, ці системи забезпечують відтворюваність повторних збірок, враховуючи платформні особливості, залежності, тестові сценарії та документацію.

Автори дослідження — Юта Сайто, Кадзунорі Сакамото та Хіронорі Васідзакі з Університету Васеда — зазначають, що коректне керування специфікаціями залежностей досі лишається однією з найскладніших задач. У масштабних проєктах саме на такі помилки припадає понад половина всіх збоїв під час збірки.

Принцип роботи mkcheck2

Класичні інструменти на кшталт ptrace створюють суттєве навантаження на систему, через що часту перевірку залежностей проводити практично неможливо. Команда з Васеди запропонувала інший шлях — трасування системних викликів за допомогою розширеного Berkeley Packet Filter, відомого як eBPF.

Саме на цій технології побудований новий інструмент mkcheck2, який суттєво зменшує час і обчислювальні витрати на пошук помилок збірки. Опис розробки під назвою «Efficient Build Dependency Verification Using eBPF and Incremental Analysis» увійшов до матеріалів 48-ї конференції IEEE/ACM з програмної інженерії 2026 року.

eBPF дозволяє виконувати ізольовані програми прямо в просторі ядра — для мережевих операцій, спостережності, безпеки та інших низькорівневих завдань. Цю технологію вже застосовують для оптимізації, зокрема у сервісі Meta Strobelight.

Дослідники пояснюють, що ptrace вимагає постійного призупинення процесів і перемикання контексту під час кожного системного виклику. Натомість їхнє рішення виконується повністю в межах ядра та практично не заважає процесу збірки.

Результат: з 21 хвилини до 24 секунд на один коміт

Випробування на численних проєктах з відкритим кодом підтвердили: mkcheck2 знижує накладні витрати на виявлення помилок у залежностях до 99,7% порівняно з підходами на базі ptrace, при цьому точність виявлення не страждає.

На повному наборі з 300 проєктів, побудованих на Make, інкрементальний аналіз показав такі показники середнього часу аналізу на один коміт:

  • Існуючий підхід — 1267,49 секунди
  • mkcheck2 — 23,56 секунди
  • Приріст швидкості — приблизно у 54 рази

Автори вважають, що такий результат робить безперервну перевірку залежностей цілком реалістичною для повсякденної розробки.

Що поки не вирішено

Самі розробники визнають наявність низки обмежень:

  • рішення функціонує лише на Linux, тож на інших операційних системах подібного пришвидшення чекати не варто
  • залишаються труднощі з певними типами надлишкових залежностей
  • відстеження доступу до відображених у пам'ять областей поки що реалізовано недосконало
  • інструмент погано розпізнає залежності динамічно завантажуваних бібліотек
  • окремі складнощі виникають із мережевими залежностями та розподіленими системами збірки

Попри перелічені застереження, зменшення накладних витрат аж до 99,7% здатне заощадити командам розробників значну кількість часу.

Джерело: Highload.tech