# ccache Vor- und Nachteile?

## 72_6f_6c_61_6e_64

Hallo,

man liest immer wieder, wie einem User von ccache abraten, und andere davon schwärmen.

CCACHE speichert doch einfach kompilierte Teile um sie später nicht nocheinmal kompilieren zu müssen.

Das heißt dass es eigentlich, sofern genug Platz für einen cache vorhanden ist schneller geht etwas zu installieren oder?

Wird er schneller, wenn man mehr Cache hat?

Warum wird einem abgeraten? Wo sind Fehler oder Bugs? Ist es so schwer zu konfigurieren?

LG Roland

----------

## Necoro

https://forums.gentoo.org/viewtopic-t-834026-highlight-ccache.html

----------

## mv

 *72_6f_6c_61_6e_64 wrote:*   

> CCACHE speichert doch einfach kompilierte Teile um sie später nicht nocheinmal kompilieren zu müssen.

 

Ja.

 *Quote:*   

> Das heißt dass es eigentlich, sofern genug Platz für einen cache vorhanden ist schneller geht etwas zu installieren oder?

 

Ja, falls exakt dieses File (mit exakt den selben Header-Files) bereits kompiliert wurde. Ansonsten wird es etwas langsamer, weil vor der Kompilation geprüft werden muss, ob das File (mit passenden Headern) bereits kompiliert wurde, und nach der Compilation das erzeugte .o-File in den Cache kopiert wird.

 *Quote:*   

> Wird er schneller, wenn man mehr Cache hat?

 

Wenn man ein Paket unmittelbar hintereinander (zu Testzwecken bei der Entwicklung mit nur leichten Änderungen in .c/.cc/.cpp-Files) mehrmals kompiliert, ist die Größe weitgehend egal. Um im "normalen" Update-Betrieb profitieren zu können, sollte der Cache schon ziemlich groß sein: Im Idealfall so groß, wie alle installierten Binaries (ohne Daten) zusammen. Bei Compression (>=ccache-3) ca. 4GB ist bei einem "typischen" Desktop meiner Erfahrung nach vernünftig.

 *Quote:*   

> Warum wird einem abgeraten?

 

So ziemlich der einzige, der vehement abrät, ist Diego, der eine Super-Maschine hat: Wenn der Rechner so schnell ist, dass die Compilationszeit i.W. tatsächlich durch den IO bestimmt wird, bringt es wohl in der Tat wenig, diese Zeit sich durch zusätzlichen IO zu "erkaufen". So als Faustregel würde ich sagen: Wenn Dein Rechner es schafft, einen gut konfigurierten Kernel in deutlich unter 1 Minute zu kompilieren, wirst Du vom ccache höchstens Nachteile haben. Wenn es 10-20 Minuten dauert, bringt der ccache enorm viel; durch den zusätzlichen IO verlierst Du vielleicht 1 Minute, aber schon bei ein paar Treffern ist das wieder "drin".

 *Quote:*   

> Wo sind Fehler oder Bugs?

 

Der Hauptnachteil ist der: Wenn Dir mitten in der Kompilation der Rechner hängenbleibt, startest Du mit Reemergen des Pakets bei 0, während wenn Dir der ccache durch Hängenbleiben des Rechners abnibbelt, kann es sein, dass Du bei reemerge einen Fehler wiederholt erhälst, der gar nichts mit dem Paket sondern nur mit dem vorherigen Absturz zu tun hat. Gentoo Developer haben Angst vor entsprechenden irreführenden Bugreports...

 *Quote:*   

> Ist es so schwer zu konfigurieren?

 

Nein, ist ein Kinderspiel: FEATURES=ccache und fertig... (bei >=ccache-3 empfiehlt es sich, noch CCACHE_BASEDIR="${PORTAGE_TMPDIR}/portage" zu setzen sowie ggf. den Cache einzuschalten o.ä., da dies Portage derzeit noch nicht automatisch macht. Das ist zwar alles optional, bringt aber doch noch einen zusätzlichen kleinen Geschwindigkeitsschub).

----------

## 72_6f_6c_61_6e_64

Das heißt ich sollte es auf einem 1,66GHz Rechner durchaus verwenden?

Sollte man den cache von ccache auf eine extra Partition legen? Wenn ja welches ist für diesen Zweck das beste Filesystem? (Root läuft mit ext4)

Aber tmpfs nutzt mir mit 1GB RAM überhaupt nix oder?

LG Roland

----------

## mv

 *72_6f_6c_61_6e_64 wrote:*   

> Sollte man den cache von ccache auf eine extra Partition legen? Wenn ja welches ist für diesen Zweck das beste Filesystem? (Root läuft mit ext4)

 

Schaden kann eine extra Partition vermutlich nicht: Da die ccache-Files typischerweise sehr klein sind, erhält man im Falle von root sonst vielleicht eine leicht untypische Nutzung, die möglicherweise die Fragmentierung im Schnitt etwas erhöhen kann. (Allerdings höre ich selbst nicht auf meinen Rat und habe keine großen Nachteile feststellen können, aber auch keine Benchmarks gemacht). Als Filesystem bietet sich vielleicht reiser an (wegen der kurzen Files) oder auch ext4 ohne Journal: Journal lohnt wohl eher nicht; wenn man Probleme bekommt, kann man den Cache ja einfach komplett löschen.

 *Quote:*   

> Aber tmpfs nutzt mir mit 1GB RAM überhaupt nix oder?

 

Was meinst Du mit tmpfs im Zusammenhang mit ccache? Beim Herunterfahren alles umkopieren? (Der Punkt ist doch, dass man ccache für spätere Neukompilationen/Upgrades von Paketen haben will - bei der Erstkompilation eines Pakets hilft ccache gar nichts [von exotischen Ausnahmen mal abgesehen]).

Aber 1-2 GB RAM kommt ohnehin an das heran, was der Compiler bei großen Projekten selbst braucht - da irgendetwas abzuzweigen, ist fast in jedem Fall kontraproduktiv.

----------

## 72_6f_6c_61_6e_64

Wie formatiert man auf ext4 ohne Journal?

was für ein Programm würdest du verwenden um die Home partition zu verkleinern und eine 5GB Cache Partition zu erzeugen?

----------

## Yamakuzure

Also ich habe ccache von allen Rechnern runtergeworfen.

Das Problem: Bei einem Update wirst du kaum einen ccache-Treffer haben, das heißt dein System verbrät Zeit damit nach einer vorkompilierten .o zu suchen, die es nicht gibt. Dafür müssen die Quelldateien untersucht, ein Hash gebildet, und dann ein _riesiger_ Dateibaum nach einer passenden .o Datei durchsucht werden. (Wer bei einer CCACHE_SIZE von 2G mal ein rm -rf auf den Ordner gemacht hat, weiß, was "riesig" heißt...)

Ich habe bei allen Rechnern und regulärem (wöchentlichen) Update-Betrieb nie eine Trefferquote von mehr als 3% erhalten. Das heißt, dass ccache bei mir bei 97% aller zu kompilierenden Dateien scheiterte, und nach vertaner Zeit eh kompiliert werden musste.

ccache bringt nur einen Vorteil, wenn man häufig die gleichen Quellen kompiliert. Aber die gleichen Quellen inklusive _aller_ Abhängigkeiten. Wie oft kommt das in einem normalen Betrieb vor? So gut wie nie.

----------

## mv

 *72_6f_6c_61_6e_64 wrote:*   

> Wie formatiert man auf ext4 ohne Journal?

 

Vermutlich durch (temporäres) Löschen von "features=has_journal" in der /etc/mke2fs.conf, vielleicht gibt es auch eine passende Option bei mke2fs. Du kannst das feature auch im Nachhinein mit tune2fs löschen. Ob die Elimination des Features tatsächlich Zeit spart, musst Du natürlich selbst probieren...

 *Quote:*   

> was für ein Programm würdest du verwenden um die Home partition zu verkleinern und eine 5GB Cache Partition zu erzeugen?

 

Erstmal dicke Warnung: Solche Operationen auf keinen Fall ohne Backup durchführen. (Außerdem: Ich habe ja selbst gesagt, dass ich diesbezüglich auf meinen eigenen Rat nicht gehört habe und der ccache einfach auf einer anderen Partition "mit"-läuft). Zum Umpartitionieren benutze ich immer parted, weil dies das einzige ist, bei dem Windows die Partitionen bisher immer ohne Probleme akzeptiert hat (das ist natürlich nur interessant, falls Du mindestens eine DOS-Partition hast); nach dem Verkleinern unbedingt einen Filesystemcheck über die Partition laufen lassen!

----------

## 72_6f_6c_61_6e_64

So wie ich das jetzt verstanden habe, bringt es einem nur Vorteile wenn man oft ähnliche Versionen eines Programms installiert, was ich nicht vorhabe.

Ich glaube ich bleibe bei der einfachen Variante und lasse es weg.

LG Roland

----------

## mv

 *72_6f_6c_61_6e_64 wrote:*   

> So wie ich das jetzt verstanden habe, bringt es einem nur Vorteile wenn man oft ähnliche Versionen eines Programms installiert

 

Also das, was man typischerweise tut, wenn man sein System auf dem Laufenden hält.

----------

## franzf

Also, "ähnliche" Versionen ist schon arg optimistisch. In irgend einem "globalen" Header tut sich immer was. Seis ein VERSION.h, config.h, ... Dann muss alles neu gebaut werden, auch wenn es nur dieser eine Header ist, der ein Update erfahren hat. Ich hab recht lange ccache verwendet, es hat nicht wirklich was gebracht. Ich hatte hauptsächlich cache_misses. Die wenigen Hits (<5%) haben nicht wirklich den Aufwand gerechtfertigt. Hier läuft ein normales Desktop-System mit kde4.

Wo ccache einiges bringt (bringen kann) sind gentoo-revison-bumps oder remerges (USE geändert, revdep-rebuild, ...). Wer hauptsächlich Testing fährt, und oft ein Revbump mitnimmt, wird profitieren.

----------

## mv

 *franzf wrote:*   

> Also, "ähnliche" Versionen ist schon arg optimistisch. In irgend einem "globalen" Header tut sich immer was. Seis ein VERSION.h, config.h, ...

 

VERSION.h wird bei vernünftigen Paketen nur von 1-2 Files inkludiert. Wie oft config.h inkludiert wird, hängt sehr vom Paket ab, und wie oft es geändert wird, auch.

 *Quote:*   

> Die wenigen Hits (<5%) haben nicht wirklich den Aufwand gerechtfertigt.

 

Normal sind bei typischer Nutzung 17-40 Prozent Hits (wobei ich bei meinen Systemen eigentlich nie weniger als 25 Prozent festgestellt habe). Die Hitzahl sinkt natürlich deutlich, wenn eine neue gcc-Version herauskommt, weil dann der alte Cache wertlos wird. Vermutlich hast Du in einer Zeit getestet, in der der gcc häufig geupdated wurde oder in der wichtige Header-Files der glibc häufig umgestellt wurden. Die Prozentzahl der Hits sagt auch nur bedingt etwas aus: Gerade die Files, die besonders lange zum Kompilieren brauchen (etwa irgendwelche Tabellen/halbautomatisch erzeugte Umrechnungsformeln für Multimediasachen) bleiben bei vielen Versionen gleich und benötigen auch keine "globalen" Header-Dateien. Und selbst 5% Hits bei "normalen" Files würden sich bei einigen meiner Systeme (K7, Pentium3) schon lohnen - bei meinem CoreDuo dürfte es ungefähr egal sein.

 *Quote:*   

> Hier läuft ein normales Desktop-System mit kde4.

 

Bei mir auch.

 *Quote:*   

> Wer hauptsächlich Testing fährt, und oft ein Revbump mitnimmt, wird profitieren.

 

Nicht nur bei Testing: xulrunner, seamonkey, qt, kdelibs haben ja schon fast routinemäßig regelmäßige Security-Upgrades, jetzt vor kurzem gerade glibc. Wenn man da statt 1-5 Stunden jeweils nur 2-10 Minuten warten muss, wird der im Vergleich dazu mikroskopische IO-Geschwindigkeitsverlust bei einem worst-case Paket vollkommen unbedeutend.

----------

## 72_6f_6c_61_6e_64

Das ist schön, im IRC rät einem jeder von ccache ab, aber hier kommt laufend Schlechtmache und anschließend höchste Töne.

Ich verfolg das noch ein paar Wochen bevor ich mich entscheide, jetzt wo es gerade spannend wird.

LG Roland

----------

## 72_6f_6c_61_6e_64

Neue Frage: Welche Version von ccache nehm ich? 2 oder 3?

----------

## mv

 *72_6f_6c_61_6e_64 wrote:*   

> Neue Frage: Welche Version von ccache nehm ich? 2 oder 3?

 

Das ist so ähnlich, wie die Frage, ob man lieber Testing oder stable nimmt: ccache-3 hat schon etliche Vorteile (Kompression, wodurch 4GB Cache-Größe ausreichen; direct mode, wodurch die IO-Last etwas verringert wird; relative Pfade, was die Hits erhöht), und bei mir hat es noch keine Probleme gemacht. Aber es ist halt noch nicht von so vielen Leuten getestet und kann daher bei irgendwelchen Systemen irgendwelche unvorhergesehenen Probleme machen, auch wenn ich mir schwer vorstellen kann, dass das der Fall ist.

----------

## mv

 *72_6f_6c_61_6e_64 wrote:*   

> Das ist schön, im IRC rät einem jeder von ccache ab

 

Mein Eindruck ist, dass Diego an vielen Stellen FUD bzgl. ccache gestreut hat, und viele diese Ansichten nun ungeprüft übernehmen. Oft hat Diego ja auch recht, aber dies zeigt sehr schön, dass man auch sonst gutinformierten Quellen gegenüber skeptisch bleiben sollte.   :Wink: 

----------

## schachti

Ich fahre ein testing-System, update also regelmäßig, und habe eine ziemlich gute Trefferquote:

```

cache hit (direct)                  9046

cache hit (preprocessed)           10902

cache miss                         29027

```

Ich denke schon, dass sich ccache bei mir lohnt...

----------

## mv

 *schachti wrote:*   

> 
> 
> ```
> 
> cache hit (direct)                  9046
> ...

 

Mal hier zum direkten Vergleich zwei Systeme von mir (größtenteils stable, aber unstable toolchain und texlive):

```
cache hit (direct)                 84664

cache hit (preprocessed)           38247

cache miss                        358142
```

und 

```
cache hit (direct)                123795

cache hit (preprocessed)           33205

cache miss                        370800
```

Möglicherweise hat die viel höhere Anzahl an Files damit zu tun, dass ich auch Kernel-Compilation als User portage über den selben cache laufen lasse; oder ich habe einfach mehr Pakete installiert... die direct hits hängen vielleicht damit zusammen, dass ich CCACHE_SLOPPINESS maximal gesetzt habe.

----------

## Yamakuzure

So. Ich weiß, der letzte Post ist schon einen Monat her, aber da ich meinen Laptop gerade auf GCC-4.5.1 umstelle, ccache-3.1 anscheinend recht schmerzfrei sein soll, und ich kein Dual-Boot mehr brauche (Juhuu! Keine Platzprobleme mehr!), habe ich beschlossen ccache mal wieder zu nutzen.

Derzeit baue ich die Toolchain neu, danach gibts die Klassiker "emtytree @system" und "emptytree @selected". Ich bin mal gespannt, was "ccache -s" danach ausspuckt. Aber es könnte wohl tatsächlich wieder ein ordentliches tool werden, denn nach dem ich sys-kernel/linux-headers, app-admin/eselect, sys-devel/gcc-config, sys-devel/binutils-config und sys-devel/binutils (derzeit läuft das Bauen der glibc) fertig habe, meldet ccache bereits: (gekürzt)

```
sed-notebook ~ # ccache -s

cache directory                     /home/.ccache

cache hit (direct)                    79

cache hit (preprocessed)              55

cache miss                          2435

called for link                       32

autoconf compile/link                285

files in cache                      7059

cache size                          52.4 Mbytes

max cache size                       4.0 Gbytes
```

So viele hits bei einem _leeren_ ccache und einfachem Mergen?   :Shocked:  *staun*

Ich habe fest an eine serh lange bestehende "0" geglaubt...

----------

## franzf

```
cache directory                     /home/.ccache 
```

Und portage verwendet auch /home/.ccache?

----------

## mv

 *Yamakuzure wrote:*   

> Derzeit baue ich die Toolchain neu, danach gibts die Klassiker "emtytree @system" und "emptytree @selected"

 

Wie schon franzf schrieb, hast Du vergessen "CCACHE_DIR=/var/tmp/ccache" vor Dein Kommando zu stellen - sonst erhältst Du Informationen über den falschen Cache. Aber nach "-e @system" wird Dir ccache bei "-e @selected" kaum helfen, außer Du nimmst gcc ausdrücklich aus dem ersten Kommandos heraus: Sonst hast Du ja einen neuen C-Compiler, und damit wird der zum alten Compiler gehörende Cache nutzlos.

----------

## Yamakuzure

nein, habe ich nicht:

```
sed-notebook env # env | grep CCACHE                                                                                                                             

CCACHE_SIZE=4G

CCACHE_LOGFILE=/var/log/ccache.log

CCACHE_DIR=/home/.ccache

CCACHE_COMPRESS=1
```

Aber gut, hier die neuen Statistiken (gekürzt) nach einem Neubau von @system (536 packages! Ich muss _dringend_ aufräumen!) : 

```
cache directory                     /home/.ccache

cache hit (direct)                 17614

cache hit (preprocessed)            5106

cache miss                         69225

files in cache                    170965

cache size                           3.1 Gbytes

max cache size                       4.0 Gbytes
```

Somit ergibt sich:

91.945 Anfragen

22.720 Treffer  : 24,71%

69.225 verfehlt : 75,29%

Eine Quote von ca. einem Viertel bei einem Neubau auf leerem Cache ist schon phantastisch!

 *mv wrote:*   

> Aber nach "-e @system" wird Dir ccache bei "-e @selected" kaum helfen, außer Du nimmst gcc ausdrücklich aus dem ersten Kommandos heraus: Sonst hast Du ja einen neuen C-Compiler, und damit wird der zum alten Compiler gehörende Cache nutzlos.

 Ja, das kam mir auch schon in den Sinn. Ich bin auch am Überlegen, ob ich @selected überhaupt neubauen möchte. Laut der man page von ccache wird die mtime des compilers geprüft, das würde also genau alles invalidieren.

Kann man, ohne eine manuelle Liste zu erstellen, gezielt Pakete von "--emptytree" ausschließen?

Edith schimpft: Einfach mal man page lesen! *man emerge wrote:*   

> --exclude ATOMS
> 
> A space separated list of package names or slot atoms.  Emerge won't  install any ebuild or binary package that matches any of the given package atoms.

   :Rolling Eyes: 

----------

