# Gentoo ottimizzare la compilazione

## Yugi

Salve so che si puo' usare CCACHE o DISTCC e MAKEOPTS="-jN" per ottimizzare le compilazioni.

DISTCC da quello che ho capito pero' richiede che esistano almeno 2 o piu'  "server" Gentoo.

volevo sapere, ma oltre a CCACHE e DISTCC (forse non l'ho trovato io) esistono altri modi per ottimizzare la compilazione ??

Un'altra cosa ho letto sul manuale Gentoo che esistono pacchetti precompilati per Openoffice, Mozilla-firefox, etc ma dove posso trovare l'elenco completo di questi pacchetti ?? (uso una architettura x86)

----------

## .:chrome:.

 *Yugi wrote:*   

> volevo sapere, ma oltre a CCACHE e DISTCC (forse non l'ho trovato io) esistono altri modi per ottimizzare la compilazione ??

 

ccache lascia un po' il tempo che trova. distcc è uno strumento valido, ma non sempre è applicabile, per sveriate ragioni

 *Yugi wrote:*   

> dove posso trovare l'elenco completo di questi pacchetti ?? (uso una architettura x86)

 

sono quelli il cui nome termina con "-bin"

----------

## Ic3M4n

```
eix -c "\-bin"
```

e se non hai eix 

```
emerge eix
```

  :Wink: 

----------

## Yugi

forse voi che usate gentoo da piu' tempo di me potete dirmi se quello che mi e' venuto in mente essiet gia' o se e' una cavolata.

Stavo pensando, se era possibile utilizzando emerge (tramite forse qualche flag) invece di vedere pagine e pagine di codice fare in modo che appaia la percentuale di avanzamento sia globale che riferita al singolo pacchetto... secondo il mio modesto parere sarebbe piu' utile.

----------

## MeMyselfAndI

non credo sia fattibile, almeno non nel senso che intendi te: potresti avere una barra che ti dice a che punto dell'emersione sei : configure, make , make install, ma non puoi sapere quanto tempo manca alla fine di una di queste tre fasi, almeno non con precisione (l'unico metodo che mi viene in mente e' usare genlop che tiene memoria del tempi di compilazione precedenti, ma e' cmq una media non sempre reale.)

----------

## Yugi

 *MeMyselfAndI wrote:*   

> non credo sia fattibile, almeno non nel senso che intendi te: potresti avere una barra che ti dice a che punto dell'emersione sei : configure, make , make install, ma non puoi sapere quanto tempo manca alla fine di una di queste tre fasi, almeno non con precisione (l'unico metodo che mi viene in mente e' usare genlop che tiene memoria del tempi di compilazione precedenti, ma e' cmq una media non sempre reale.)

 

penso che anche se fosse non precisa andrebbe bene lo stesso, giusto per avere un idea.

----------

## randomaze

 *Yugi wrote:*   

>  *MeMyselfAndI wrote:*   (l'unico metodo che mi viene in mente e' usare genlop che tiene memoria del tempi di compilazione precedenti, ma e' cmq una media non sempre reale.) 
> 
> penso che anche se fosse non precisa andrebbe bene lo stesso, giusto per avere un idea.

 

Per il tempo di compilazione del pacchetto in corso e la stima sul rimanente rispetto alle precedente compilazione basta che dai il comando:

```
genlop -c
```

Per avere un idea del tempo globale riferendosi alle precedenti compilazioni basta dare:

```
emerge -p X Y Z | genlop -p
```

Per mettere le due cose insieme e far apparire una barra (genlop on steroids?).... si accettano volontari.

----------

## 102376

bhe secondo me serve a poco, cmq sempre meglio che vedere una sfilza di codice che scorre, che secondo me aumenta anche il tempo di compilazione, esiste un metodo per non far vedere a video la compilazione?

forse per fare una stima si potrebbe anche prendere la dimensione del file da scaricare, disolito + è grande il pacchetto + c metta a compilare

----------

## Cazzantonio

 *zocram wrote:*   

> forse per fare una stima si potrebbe anche prendere la dimensione del file da scaricare, disolito + è grande il pacchetto + c metta a compilare

 Non c'entra assolutamene nulla... ma proprio nulla...

----------

## 102376

ma scusa un file che pesa 100kB ci mettera meno di un file che ne pesa 10.000kb

forse non sarà sempre vero pero' mi pare che kde ci metta  molto di + a compilare che alsa-utils

----------

## lavish

 *zocram wrote:*   

> ma scusa un file che pesa 100kB ci mettera meno di un file che ne pesa 10.000kb
> 
> forse non sarà sempre vero pero' mi pare che kde ci metta  molto di + a compilare che alsa-utils

 

Il C e' generalmente molto piu' veloce da compilare del C++.

python generalmente non si compila e via dicendo...

Inutile citare i giochi che di solito hanno poco codice e molti file di media...

----------

## 102376

 *lavish wrote:*   

>  *zocram wrote:*   ma scusa un file che pesa 100kB ci mettera meno di un file che ne pesa 10.000kb
> 
> forse non sarà sempre vero pero' mi pare che kde ci metta  molto di + a compilare che alsa-utils 
> 
> Il C e' generalmente molto piu' veloce da compilare del C++.
> ...

 

se la metti così è verissimo, hai ragione tu,pero' si potrebbe tenere in considerazione anche questo parametro, oltre a tutto il resto

----------

## .:chrome:.

 *zocram wrote:*   

> ma scusa un file che pesa 100kB ci mettera meno di un file che ne pesa 10.000kb
> 
> forse non sarà sempre vero pero' mi pare che kde ci metta  molto di + a compilare che alsa-utils

 

bravo. hai fatto proprio un bell'esempio!

KDE è scritto in C++, e come dice lavish è molto più lento e macchinoso da compilare rispetto al C.

allo stesso modo alcuni linguaggi interpretati (java e python) sono molto più lenti da eseguire rispetto ad altri (perl). tuttavia anche questa velocità dipende dall'esecutore: java 6 è imparagonabile in quanto a velocità, che è nettamente superiore a quella di tutte le altre versioni.

rimanendo comunque nei linguaggi compilati c'è anche da considerare i parametri passati ai compilatori che possono variare drasticamente il tempo ed il carico della compilazione.

morale della favola: ci sono troppe varibili in ballo per poter fare delle stime sensate.

ma poi, è così importante sapere i tempi di compilazione? conosco molte persone che vivono benissimo pur ignorando il tempo di compilazione di KDE...

tornando in-topic, dopo questa bella fila di post off-topic, se veramente si è interessati a ridurre tempo e carico di compilazione, sarebbe cosa buona non stare ad osservare l'output (tanto il programma si compila lo stesso!) ma rinchiuderlo in una sessione screen e distaccarla.

il motivo è semplice: lo scrolling è oneroso per la CPU, nonché inutile. per chi ne volesse una dimostrazione, basta provare questi due comandi: "time eix > /dev/null" e "time eix".

----------

## fedeliallalinea

 *.:chrome:. wrote:*   

> bravo. hai fatto proprio un bell'esempio!
> 
> KDE è scritto in C++, e come dice lavish è molto più lento e macchinoso da compilare rispetto al C.
> 
> allo stesso modo alcuni linguaggi interpretati (java e python) sono molto più lenti da eseguire rispetto ad altri (perl). tuttavia anche questa velocità dipende dall'esecutore: java 6 è imparagonabile in quanto a velocità, che è nettamente superiore a quella di tutte le altre versioni.
> ...

 

Oltre a questo un artwork potrebbe tenere 10Mb ma installarsi prima visto che la maggior parte sara' costituito da immagini da copiare in un certo path

----------

## Yugi

non volevo alzare un vespaio. il mio mi era parso un suggerimento in generale dato, che giustamwente come dice chrome, non serve starsene a vedere il video, ma appunto perche' uno non sta a vedere il video mi era venuto in mente che forse era piu' utile vedere una "percentuale di avanzamento lavori" del codice.

per la compilazione provero a studiarmi screen.

----------

## djinnZ

Un paio di pacchetti, non ricordo quali, hanno iniziato timidamente a presentare una percentuale di avanzamento riferita agli step però.

```
uno lo ho trovato: app-mobilephone/gammu
```

devo dire che l'idea non è malvagia e torna utile per profondi quesisti esistenziali quali "fermo la compilazione di OOo dopo appena sei ore?"

----------

## !ico

qui viene presentato uno script che presenta la percentuale di avanzamento dei pacchetti in compilazione:

https://forums.gentoo.org/viewtopic-t-446277-highlight-tempo.html

a volte sballa un po' però..   :Confused: 

domanda: si può usare emerge nomepacchetto > /dev/null?

quali sono le controindicazioni?

ola  :Wink: 

----------

## zolar czakl

 *!ico wrote:*   

> domanda: si puï¿½ usare emerge nomepacchetto > /dev/null?
> 
> quali sono le controindicazioni?

 

https://forums.gentoo.org/viewtopic.php?t=210211&highlight=tip

----------

## !ico

ancora una volta troppo pigro   :Confused: 

grazie mille!

ola  :Wink: 

----------

## cloc3

 *zolar czakl wrote:*   

> 
> 
> https://forums.gentoo.org/viewtopic.php?t=210211&highlight=tip

 

questa discussione è oramai datata.

adesso i log di emerge sono stivati accuratamente in $PORT_LOGDIR .

di conseguenza mandare l'output in /dev/null non dovrebbe essere controindicato.

tra l'altro, $PORT_LOGDIR funziona anche per chi usa portage-bashrc-ng in tmpfs.

io però me ne frego dei tempi ed uso ancora il vecchio 'emerge pacchetto>out.txt 2>error.txt` che mi lascia una comoda doppia copia in /root.

----------

