# [solved] emerge beschleunigen

## FrancisA

Hallo,

vielleicht eine etwas "einfältige" Frage, aber ich stelle sie trotzdem.

bei jedem emerge Paket kommen ja die Checks, die den ganzen Prozess beim updaten verlangsamen.

z.B:

```
checking for mbsrtowcs... yes

checking for mbschr... no

checking for wcrtomb... yes

checking for wcscoll... yes

checking for wcsdup... yes

...

```

Gibt es eine Möglichkeit, diese zu unterbinden oder noch besser (nur einmal durchlaufen zu lassen).

Ich meine, wenn 200 oder mehr Pakete upgedated werden, wird es schon etwas langweilig; weil wenn ein check einmal erfolgreich war, wird er es die nächsten 199 mal auch sein.Last edited by FrancisA on Sat Nov 12, 2011 10:50 pm; edited 1 time in total

----------

## disi

Das ist upstream, sprich der Entwickler tested nach den vorhandenen Resourcen.

----------

## franzf

ccache wäre eine Möglichkeit. Allerdings gibt es immer mal ganz komische Probleme, die dann nur durch Deaktivieren von ccache bzw. dem Leeren des Cache von ccache zu lösen sind.

----------

## FrancisA

 *disi wrote:*   

> Das ist upstream, sprich der Entwickler tested nach den vorhandenen Resourcen.

 

Ok, ja, ich kann mir vorstellen, dass das nicht so leicht ist. Ich denke da an einen Cache, der das zwischenspeichern könnte. Einmal auf stdlib geprüft => im Speicher behalten. Ich denke, das wird entweder a) nicht so leicht sein oder b) zu unwichtig sein, sonst gäbe es eine solche Option vielleicht schon.   :Wink:  Es würde das ganze halt doch beschleunigen.

----------

## cryptosteve

Kurzum: Nein, die Checks kann man nicht verknappen oder nach einmaligem Check gänzlich wegfallen lassen. 

Es gibt haufenweise HOWTOs, wie man portage/emerge letztlich beschleunigen kann. Vieles davon hat Vor- und Nachteile. Was allerdings nie schaden kann, ist viel RAM.  :Smile: 

----------

## FrancisA

 *franzf wrote:*   

> ccache wäre eine Möglichkeit. Allerdings gibt es immer mal ganz komische Probleme, die dann nur durch Deaktivieren von ccache bzw. dem Leeren des Cache von ccache zu lösen sind.

 

Ahm, ja, ccache habe ich ohnehin schon in Verwendung. Aber vielleicht wäre das ohne ccache ja noch langsamer. Ich frage eher aus Interesse. So richtig machen die Checks das "Kraut ja auch nicht mehr fett". Das mounten von tmpfs auf /var/tmp/portage hat ja erfreulicherweise das ganze schon spürbar beschleunigt, so weit ich das sehe.   :Wink: Last edited by FrancisA on Fri Nov 11, 2011 7:39 pm; edited 1 time in total

----------

## AmonAmarth

war nicht genau dieser punkt der grund für die einführung von cmake bei KDE um die monolitischen pakete durch meta pakete auszutauschen? aber wie sicherlich schon zu vermuten ist, ist dies wieder vom upstream abhängig, also entscheiden die entwickler und nicht die distribution

----------

## cryptosteve

 *FrancisA wrote:*   

> Ahm, ja, ccache habe ich ohnehin schon in Verwendung. Aber vielleicht wäre das ohne ccache ja noch langsamer.

 

Kommt ccache denn bei den Checks überhaupt schon zum Einsatz? Ich hatte es bislang so verstanden, dass es erst beim eigentlichen Bauen (make) greift ...

----------

## FrancisA

 *AmonAmarth wrote:*   

> war nicht genau dieser punkt der grund für die einführung von cmake bei KDE um die monolitischen pakete durch meta pakete auszutauschen? aber wie sicherlich schon zu vermuten ist, ist dies wieder vom upstream abhängig, also entscheiden die entwickler und nicht die distribution

 

Asso, danke für die Info. Also haben sich auch schon andere Leute darüber Gedanken gemacht.

----------

## FrancisA

 *cryptohappen wrote:*   

>  *FrancisA wrote:*   Ahm, ja, ccache habe ich ohnehin schon in Verwendung. Aber vielleicht wäre das ohne ccache ja noch langsamer. 
> 
> Kommt ccache denn bei den Checks überhaupt schon zum Einsatz? Ich hatte es bislang so verstanden, dass es erst beim eigentlichen Bauen (make) greift ...

 

Ah ja, da hast du schon recht.

----------

## py-ro

Es gab in Portage tatsächlich mal die Möglichkeit eines configure-Caches, das hat aber insgesamt sehr viel mehr Probleme gemacht als es jemals Zeit hätte sparen können und wurde daher fallengelassen.

Bye

Py

----------

## FrancisA

 *py-ro wrote:*   

> Es gab in Portage tatsächlich mal die Möglichkeit eines configure-Caches, das hat aber insgesamt sehr viel mehr Probleme gemacht als es jemals Zeit hätte sparen können und wurde daher fallengelassen.
> 
> Bye
> 
> Py

 

Ich denke mittlerweile, dass diese Vorabchecks eh kaum mehr ins Gewicht fallen (ich bin nämlich gerade beim lib boost compilieren und ein Ende ist nicht in Sicht)   :Wink:   :Rolling Eyes: 

----------

## cryptosteve

Das siehst Du anders, wenn es auf Deiner alten Kiste erst drei Stunden kompiliert und dann mit einem Fehler abbricht, weil eine Dependency fehlt, deren Fehlen im Check schon aufgefallen wäre.

----------

## mv

 *py-ro wrote:*   

> Es gab in Portage tatsächlich mal die Möglichkeit eines configure-Caches, das hat aber insgesamt sehr viel mehr Probleme gemacht als es jemals Zeit hätte sparen können

 

Ja, davon kann ich nur abraten (ist auch nicht mehr im portage-Baum). Ich hatte auch einmal mit einer eigenen config.site rumgespielt, um die vermeintlich eindeutigen Tests festzulegen, hatte dann aber systematisch immer mehr streichen müssen, weil es jeweils zu viele Ausnahme-Pakete gab. Am Schluss blieb nichts mehr übrig, das auch nur halbwegs zuverlässig für alle Pakete ging... Inzwischen sieht meine config.site nur noch minimal aus: 

```
: ${enable_static=no}

: ${enable_fast_install=yes}

: ${enable_new_ldflags=yes}

: ${enable_silent_rules=yes}

enable_dependency_tracking=yes
```

Wobei sich die letzte oder vorletzte Zeile demnächst ändern wird, wenn gentoo wie geplant per Default --disable-silent-rules benutzt...

----------

