Witam,
widzial ktos gdzies kiedys jakis zbior porad jak przyspieszyc kompilacje programow w c++?
Niedawno czytalem, ze podobno w przytlaczajacej wiekszosci programow da sie skrocic czas kompilacji programu o 90% (!!!).
Zatem jak pisac kod, jak wlaczac naglowki itp aby bylo to maksymalnie szybkie? Co spowalnia najbardziej proces kompilacji?
Pozdro
a gdzie czytałeś?! jakiś punkt zaczepienia daj - czasopismo, książka, autor, może nawet link, bo to w internecie było? ciekaw jestem, bo te 90% to jakoś z d**y mi się wzięte wydaje... z drugiej strony faktycznie wiele rzeczy przyspiesza:
prekompilacja nagłówków:
np w visual studio i borland c++ można zgrupować największe nagłówki i ustawić kompilatorowi, żeby kompilował je tylko raz. Jak te nagłówki są w wielu .cpp wstawiane i są faktycznie duże (np "vcl.h" jest ogromniaste) to zysk jest ogromny.
oszczędność w stosowaniu szablonów:
taak, eksportowanie szablonów to przyszłość, obecnie każdy szablon jest w całości includowany i kompilowany w każdym pliku cpp - więc to długo trwa - jak sobie damy siana z szablonami - będzie szybciej.
podział projektu na wiele wiele mniejszych plików, zamiast jednego bydlaka - zmiana w jednym pliku pociąga tylko rebuild właśnie jego, a nie całego projektu.
coś jeszcze mi chodziło po głowie, ale wypadło. Cóż... ogólne metoda to redukowanie kodu źródłowego przeznaczonego do kompilacji i tyle. A ponieważ znakomita większość tego kodu leży w plikach nagłówkowych, to na nich się to koncentruje. Jest kilka specyficznych tricków, np:
nagłówek:
class ukryta_implementacja;
class interfejs {
private:
ukryta_implementacja* uchwyt;
public:
interfejs();
~interfejs();
// różne deklaracje metod publicznych
};
plik .cpp
class ukryta_implementacja {
// wszystkie flaki, zmienne, funkcje itp
};
interfejs::interfejs() : uchwyt(new ukryta_implementacja ) {}
~interfejs() { delete uchwyt; }
// i reszta metod, z reguły "działających" tak:
int interfejs::funkcja(argumenty) {
return uchwyt->metoda(argumenty);
}
Taka konstrukcja zapobiega rekompilacji kiedy np chcesz zmienić w klasie prywatne składowe. Bez tego triku wszystkie moduły używające twojej klasy muszą być zrekompilowane, bo nie będą zgodne na poziomie binarnym. Wkurzające, bo przecież interfejsu nie zmieniłeś tylko prywatne jakieś flaki - w ten sposób możesz tego uniknąć, dodatkowo skracasz nagłówek i jeszcze przed wścibskimi naprawdę ukrywasz prywatne dane.
No i dla każdego kompilatora idzie coś tam poustawiać, żeby szybciej szło na etapie wprowadzania poprawek - u borlanda np jakąś heurystykę można włączyć, i faktycznie jak się zrobi małe modyfikacje w źródle, to szybko mu idzie - oczywiście takiego kodu jako release bym nie puścił, ale jest...
Witam,
czytalem w ktorejs z ksiazek dot tego jezyka. Wtedy wydalo mi sie to w miare ciekawe ale nie zawracalem sobie tym glowy. Jednak projekt coraz bardziej sie rozrasta i chcialbym to przyspieszyc.
Autor wiedzial raczej co pisze bo pisal to ze swojej wieloletniej praktyki. Niestety nie pamietam ani autora ani tytulu.
Podobno cos takiego przyspiesza kompilacje. I chodzi mi wlasnie o tego typu chwyty:
Zamiast pisać tak:
plik.h
#include "KlasaA.h"
class KlasaB
{
...
KlasaA* klasaA ;
} ;
lepiej napisac tak:
plik.h
class KlasaA ;
class KlasaB
{
...
KlasaA* klasaA ;
} ;
plik.cpp
include "KlasaA.h"
...
jasne, forwardowanie które przytoczyłeś, działa na tej samej zasadzie ogólnej, o której wspomniałem: oszczędziłeś jednego include'a w jakimś "plik.h", więc użycie include "plik.h" dołącza o wiele mniej kodu. a żeby już do składników klasyA się odwoływać, to include "klasaA.h" dajesz tylko w tych plikach cpp, które tego naprawdę potrzebują.
Pamiętaj, że include to zwykłe kopiuj-wklej. Każdy inlude to rozrost kompilowanego pliku. Narysuj sobie za pomocą grafu kto co i gdzie wstawia - wyśledź wszystkie zbędne wstawienia, usuń zbędne zależnosci - widząc na grafie kto-kogo-i-dlaczego możesz nie tylko ograniczyć nagłówki, a więc kompilowany kod, ale możesz też zobaczyć błędy projektowe, jakiś chaos w plikach .h i .cpp i zareagować na to odpowiednio.
ps. poprawiłem ci już literówkę w oryginalnym poście
jeszcze jedna uwaga.. napisanie sensownego makefile'a ktory pozwoli sledzic co sie zmienilo i jedynie rekompilowac zmienione .cpp oszczedzi Ci 99% czasu rekompilacji w duzym projekcie.. ale.. trzeba go naprawde porzadnie napisac;)