Mon expérience

Je suis un peu entre-deux au sujet des jumbo builds. Mon expérience me dit que c'est vraiment efficace pour réduire les temps de builds, et j'apprécie quelques effets comme l'idée de ne pas mettre de using namespace à un niveau global. D'un autre côté ça vient avec son lot de surprises que tu as très bien décrites dans ce billet.

Au niveau des intérêts il y a aussi une réduction des temps de link (i.e. ce n'est pas qu'une question de parsing de headers). Par exemple, dans un code plein de templates, on se retrouve avec ces derniers instanciés avec les mêmes types dans plein de .o, puis le linker doit faire le tri dans tout ça. Avec un unity build il n'y a qu'une seule instanciation du template dans le gros .o, ce qui est plus simple à gérer pour le linker (en plus de ne pas avoir à charger 2000 .o en premier lieu). Je n'ai pas mesuré mais je serais surpris que cela ne soit pas un avantage dans le cadre de LTO aussi.

Mon top des trucs pénibles serait les #include manquants qui cassent le build incrémental, les fonctions static avec le même nom et la même signature dans plusieurs .cpp, et des #define qu'on retrouve dans plusieurs .cpp aussi. Ce sont les premiers problèmes que je rencontre quand je passe un projet en unity builds.

Et puis il y a aussi le problème des devs qui s'en fichent pas mal : « Le build est lent ? Achète plus de machines, et des plus grosses. Moi je continue à mettre des using namespace partout et à mettre mes templates sans instanciation explicite. »

Au final on se retrouve à faire deux builds, un incrémental et un jumbo, pour être sûr que ça fonctionne dans tous les cas, et je me demande si on y gagne vraiment :)

unity build implies a slight overhead during incremental builds

Ça dépend du projet ! Même en dev quotidien, en recompilant avec quelques fichiers modifiés ici et là, ça peut aller plus vite de passer par un unity build.