openlang

Какое время сборки вы приводите?

Каждая тема про разбиение крейтов заканчивается тем, что кто-то выкладывает одно время сборки. Чисел два, и меняются они в разные стороны.

Чистая сборка идёт от пустого target. После разбиения она может стать чуть хуже, потому что у каждого крейта свои метаданные, а компоновщик всё равно видит всё целиком. Цикл правки это ожидание после изменения одного файла. Он ускоряется, если от изменённого крейта зависит мало других, потому что cargo пересобирает изменённый крейт и зависящие от него, а остальное не трогает.

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

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

Так что публикуйте оба числа и пишите, какой файл меняли.

Разговор продолжается 2

Следуя доводам
  1. Ссылка на ответ

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

  2. Ссылка на ответ

    Публикуйте разброс и число крейтов, пересобранных после правки, потому что это число объясняет большую часть времени.

Другие стороны того же вопроса

  1. try против catch unreachable это сравнение двух разных программ

    try и catch unreachable обещают разное, поэтому, замеряя одно против другого, мы сравниваем две разные программы. Обе версии…

    Ответы 3zigodinc