Здравствуйте, boomer, Вы писали:

B>Мне всегда было интересно, почему это ninja быстрее? Основное время тратится на компиляцию и линковку и тут работает тот же компилятор/линковщик, не важно, чем собирать, хоть make, хоть ninja, хоть msbuild.
B>По факту попробовав перевести наш продукт на ninja — получили сходное время сборки.
Здесь вопрос масштаба и потребностей, ну и применимости.

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

И тем не менее — это скорее часть исполнительной сборочной машины. Впрочем в документации они и позиционируют это как некоторый ассемблер к которому нужен генератор.

MSBuild, напротив — к тому времени или выжрет немерянно памяти, или окопается в свопе, так или иначе ухудшая время сборки. Но и он претендует всё же на немного другую роль, в обычном случае.

Сейчас лишний гигабайт памяти может быть и не проблема (пока ее достаточно), но пока она (лишняя работа) выполняется — ты за нее платишь — своим временем.

Для C# в msbuild параноидальное дублирование артефактов в obj и bin. На одном слабом билд сервере с убитым IO после включения хард-линков (штатная опция в бесконечных стандартных targets)- время сборки упало с более чем часа до считанных минут.

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

Я вот не проверял на последнем мс компиляторе (в связке с мсбилдом) как он работает с респонс-файлами, но не так давно каждый инвок компилятора — это запись в %temp% этого самого рнспонс файла... Разумеется такие подходы не дают выжать полную скорость, при чем, чем больше ядер, тем больше затыков.

Здравствуйте, boomer, Вы писали:

B>Мне всегда было интересно, почему это ninja быстрее? Основное время тратится на компиляцию и линковку и тут работает тот же компилятор/линковщик, не важно, чем собирать, хоть make, хоть ninja, хоть msbuild.
B>По факту попробовав перевести наш продукт на ninja — получили сходное время сборки.
Здесь вопрос масштаба и потребностей, ну и применимости.

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

И тем не менее — это скорее часть исполнительной сборочной машины. Впрочем в документации они и позиционируют это как некоторый ассемблер к которому нужен генератор.

MSBuild, напротив — к тому времени или выжрет немерянно памяти, или окопается в свопе, так или иначе ухудшая время сборки. Но и он претендует всё же на немного другую роль, в обычном случае.

Сейчас лишний гигабайт памяти может быть и не проблема (пока ее достаточно), но пока она (лишняя работа) выполняется — ты за нее платишь — своим временем.

Для C# в msbuild параноидальное дублирование артефактов в obj и bin. На одном слабом билд сервере с убитым IO после включения хард-линков (штатная опция в бесконечных стандартных targets)- время сборки упало с более чем часа до считанных минут.

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

Я вот не проверял на последнем мс компиляторе (в связке с мсбилдом) как он работает с респонс-файлами, но не так давно каждый инвок компилятора — это запись в %temp% этого самого рнспонс файла... Разумеется такие подходы не дают выжать полную скорость, при чем, чем больше ядер, тем больше затыков.

PS: Иначе говоря когда инфраструктурные затраты станут видимыми/значимыми — тогда и эффект будет более значимым. А так, конечно, если выиграл 10мс то чего париться.