Szybsze budowanie projektu z IWYU

iwyu = include-what-you-use

Zastanawiam się czy użycie narzędzia iwyu daje zauważalne przyspieszenie kompilacji projektu.
Warto stosować ?

Widzę że iwyu rozbija include na mniejsze pliki np.

#include <iosfwd>          // for string
#include <__functional/function.h>  // for function
#include <__algorithm/max.h>  // for max
#include <__algorithm/min.h>   // for min
#include <__chrono/duration.h>    // for milliseconds, duration, duration_cast
#include <__chrono/time_point.h>  // for operator-, time_point

czy warto trzymać się tej konwencji ?

W poprzedniej firmie przy budowaniu od zera z 1h spadło nam do 20 minut.
Jednak największy zysk jest jak coś zmodyfikujesz w nagłówku i to nie powoduje, że leci kaskada przekompilowań translation unit.

Z tymi rozbijaniami na mniejsze include nie znam tej opcji.
IMO lepiej nie używać, bo te #include <__functional/function.h> jest dla mnie nie do przyjęcia (nie ma tego w standardzie).

W obecnej firmie próbuje przekonać do IWYU i do conan.

czy warto trzymać się tej konwencji ?

Nie. Prekompilowane nagłówki są mniej absorbujące i dają namacalny zysk. iwyu przydaje się w dużych projektach gdzie zebrało się trochę syfu do usuwania niepotrzebnych inkludów w .cpp dzięki czemu optymalizujesz inkrementacyjną kompilacje poprzez nie rekompilowanie niepotrzebnych jednostek.

Jak chcesz namacalną różnicę w czasie kompilacji to prekompilowane nagłówki oraz tzw. "unity build" (nie mylić z silnikiem 3D) są najlepsze. Można używać jednego i drugiego na raz. Zrobiłem o nich wpis jak to zrobić z użyciem makefile i clang O czasach kompilacji w C++ r... W VisualStudio obydwie opcje są do wyklikania.

Swoją drogą lepie by było mieć moduły z C++20 i zapomnieć o nagłówkach.
Na razie ze wsparciem jest słabo. cmake obecnie dogadał sie z gcc i msvc by generować mapę zależności dzięki czemu cmake ogranie kolejność budowania modułów.
Kitware na razie nie był w stanie na razie dogadać się z clang i apple-clang w tej materii.

Ostatni talk autora cmake.

Przeczytaj CAVEAT na github. Jak probowalem uzyc (ze 2 lata temu) to nie dzialalo. Jakas konkurencja tez nie dzialala. Natomiast jesli w jakims projekcie dziala to zdecydowanie warto. Oprocz potencjalnego przyspieszenia kompilacji nie mozna nie doceniac usuniecia smietnika z kodu i zapewnienia ze projekt sie kompiluje (a czesto nawet jak sie wydaje ze sie kompiluje to kompiluje sie mimo tego ze kod jest napisany niepoprawnie, ale inny include niejawnie includuje na 16 poziomie wglab).

Jak działa to tak, jak nie działa (co jest raczej nie jest normą, bo ten tool wymaga mappingów) to nie, szkoda czasu.
Warto użyć wspomnianych już pch i unity buildów. Jeśli chodzi o wyszukiwanie najbardziej problematycznych miejsc to polecam https://github.com/aras-p/ClangBuildAnalyzer

MarekR22 napisał(a):

W poprzedniej firmie przy budowaniu od zera z 1h spadło nam do 20 minut.

To jest normalne że aplikacje w C++ tyle się budują? :O

iwyu z mojego punktu widzenia wydaje sie przydatny bo rzeczywiście trochę się zbiera niepotrzebnych nagłówków w moim edukacyjno-ewolucyjnym modelu tworzenia oprogramowania, iwyu pokazuje jakich plików zapomniałem dodać w nagłówkach oraz iwyu pokazuje gdzie można użyć "Forward Declarations"

co do rozbijania include na drobne to wystarczy zajrzeć np. tutaj
źródła cmake

co do samego przyspieszenia to dodatkowy bonus czasu dostałem za zmianę GCC na Clang
Szybciej buduje i szybciej linkuje EXE :D