хм

хм хм

код не поменялся, а время сборки сократилось в два раза

т.е. ты по сути немножк структуру проекта поменял, нет?

да

но там было 200 проектов в солюшне, а не 3

было чо объединить

Типа есть сборка, она юзает сборку А, а её юзает сборка Б, и ты делаешь, что сборка Б юзает сборку А директивно

так?

"много было мест вида a -> b -> c
без ответвлений" я вот про это

Просто когда фронтендеры говорят про оптимизацию билда - они имеют ввиду наворчачивание зоопарка тулов

не. есть условно сборка А. Её юзает сборка Б. Которую юзает сборка С

мсбилд такое билдит последовательно, при том что компилятор вообще-т может работать паралльно (парсинг лексер).
Но компилятор бессилен, т.к. его на запустят на проекте Б пока не выполнится сборка проекта А. Косяк

Надо использовать и параллелизм компилятора и мсбилда по максимуму.

Для начала схлопнем все три проекта в один и получим параллелизм компилятора (он ограничен).
Но уже збс

Теперь разделим проект на независимые куски чтобы получить чот типа

A -
    \
B - - D

C - /

и тогда мсбилд сможет параллельно запустить A, B, C, в которых компилятор будет чот делать паралльльно
ну и на последок останется маленький проект D, который всё это юзает

короче, надо чтобы было не

A -> B -> C

а

A -
    \
B - - D

C - /

не даром же у нас рязани 32 ядра

пусть работают

Мой метод работает почти в любой экосистеме

но при этом проект разъединить ты не можешь

Т.е. это явный трейдоф, где продаешь дизайн, а покупаешь перформанс сборки

могу, но почти всегда

схлопнутый в один проект граф
A -> B -> C

будет собираться быстрее

на первом шаге да.