Valtava gch-file / gch-fileen koon optimointi?

[hkultala]

Tuli tässä ihmeteltyä projektin build-hakemiston kokoa, ja sieltä löytyi yli 400-megainen gch-file.

Tuo on joku precompiled header-file jonne menee jotain datatyyppimäärittelyjä tms muka "nopeuttamaan" käännöstä (suhtaudun tässä tilanteessa tähän hiukan spektisesti).

Mutta kun näitä build-hakemistoja on paljon ja palvelinta, jolla buildeja ajetaan on paljon käyttäjiä, nuo 400-megaiset gch-fileet alkaa tuntumaan.

Onkohan tuon koon optimoinitiin muita vaihtoehtoja kuin vaain lyhentää koodissa luokkien ja funktioiden nimiä, vai voiko sitä saada pienemmäksi jollain komentorivioptioilla jonnekin?

Ja onko mitään helppoa keinoa saada statistiikkaa, että MIKSI tuo gch-file on noin pitkä, mikä siellä sen tilan vie?

Toki koko gch-fileen generoinnin voisi ehkä disabloida mutta se kai hidastaisi käännösaikaa.

 

[d0ggie]

Jos kyseessä on on GCC, niin tuo on suoraan GGC:n (GCC GC; eli GCC Garbage Collector) eli kääntäjän oman muistihallinnan vedos. Noin pähkinänkuoressa GCC kääntää halutun esikäännettävän tiedoston sopivaan pisteeseen asti, sitten karkeasti ottaen dumppaa kaiken muistin sellaisenaan tiedostoon. Kun esikäännettyä tiedostoa sitten käytetään eli luetaan, niin sen sisältö viedään jokseenkin suoraan muistinhallinnan muistisivuiksi; so. kaikki toimintaa vaativa on jo tehty, ja muistista löytyy näin valmiiksi esikäsitelty lopputulos. Käytännössä ei aivan näin suoraviinaista, mutta noin teoriassa. Yhden lajin hibernate siis. Tuo toteutus on joiltakin osin vähän ylimalkainen, eli GCC olettaa, että muistia voidaa hallinnoida aina jostain kiinteästä osoitteesta, mikä on hivenen riippuvainen mm. mmap:n toteutuksen tasosta. Siellä on myös muna-kana -tyyppisiä ongelmia, eli luettaessa GCH/PCH-tiedostoa virheilmoituksia yritetään etsiä muistista, jota juuri ollaan lukemassa ym.

Jos arvaukseni osui oikeaan, niin tuskin ainakaan Windows pannu on käytössä. Terveisin "static const size_t pch_VA_max_size = 128 * 1024 * 1024;". Absoluuttisesti en pitäisi tuota kokoa ihmeellisenä. Jos vertaa vaikka MSVC:n vastaaviin binäärimöykkyihin, niin aika pieni tuo on. Mitä tulee kysymykseesi, niin koko pienee kun esikäännettävän tiedoston kompleksisuus pienenee. En ole koskaan yrittänyt, mutta esikäännettyä tiedostoa luotaessa voi toki kokeilla yrittää säätää GGC:n eri parametrejä. Ehkä sinne jää tarpeetonta tavaraa, joita GC ei ilman säätämistä nappaa pois. En ole erikseen tutustunut, että mitä GC syklejä ajellaan ennen muistin dumppaamista ulos. GCC:n lähdekoodistahan tuon voi kurkata jos ei halua empiirisesti tutkia.

Jos ja kun C++ moduulitoteutus saadaan GCC:n puolella toimivaksi, niin C++:n tapauksessa tuo GCH/PCH jäänee historian siipien havinaan. Ei siis välttämättä kannata hirveästi uhrata paukkuja mikäli C++-projekti on.