# [Libreoffice] Temps de compil libreoffice 4.4

## sebB

Salut,

Avez-vous le même soucis que moi?

```
Tue Dec 30 14:51:40 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 2 hours, 49 minutes and 13 seconds.

Fri Jan  2 21:27:41 2015 >>> app-office/libreoffice-4.2.8.2

       merge time: 3 hours, 02 minutes and 7 seconds.

Sun Feb 15 20:56:34 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 3 hours, 10 minutes and 44 seconds.

Sun Apr 19 18:47:34 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 8 hours, 41 minutes and 59 seconds.
```

Je passe de 3h à 9h de compil pour libreoffice.

Rien de changé dans ma config.

Les autres "gros" paquets ne changent pas: firefox, thunderbird, gcc...

Juste pour savoir si pour les futures versions je m'oriente vers la version binaire ou pasLast edited by sebB on Thu May 28, 2015 10:00 am; edited 1 time in total

----------

## k-root

```
     Tue Aug 26 23:35:32 2014 >>> app-office/libreoffice-4.2.6.2

       merge time: 4 hours, 47 minutes and 58 seconds.

     Wed Oct 15 14:10:58 2014 >>> app-office/libreoffice-4.3.1.2

       merge time: 4 hours, 54 minutes and 35 seconds.

     Fri Nov 14 13:28:41 2014 >>> app-office/libreoffice-4.3.1.2

       merge time: 5 hours, 7 minutes and 59 seconds.

     Mon Dec  8 12:25:53 2014 >>> app-office/libreoffice-4.3.4.1

       merge time: 5 hours, 3 minutes and 28 seconds.

     Fri Jan  2 09:45:05 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 5 hours, 10 minutes and 9 seconds.

     Sat Jan  3 23:06:37 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 6 hours, 19 minutes and 1 second.

     Sun Jan 11 04:17:56 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 7 hours and 6 seconds.

     Tue Apr 28 11:27:14 2015 >>> app-office/libreoffice-4.4.2.2

       merge time: 7 hours, 14 minutes and 39 seconds.
```

----------

## k-root

 *sebB wrote:*   

> Juste pour savoir si pour les futures versions je m'oriente vers la version binaire ou pas

 

si le temps est une contrainte , fonce !

----------

## 341438

Je n'ai que compilé des versions récentes, mais j'obtiens les mêmes résultats que vous:

```

$ genlop -t libreoffice

 * app-office/libreoffice

     Sat Apr 25 23:32:27 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 6 hours and 34 seconds.

     Mon May  4 16:31:44 2015 >>> app-office/libreoffice-4.4.2.2

       merge time: 6 hours, 42 minutes and 12 seconds.

```

Et merci au passage de m'avoir fait découvrir genlop!   :Very Happy: 

----------

## kopp

Perso, ça avait déjà bien augmenté sur la version précédente lors d'une recompil, mais pendant laquelle j'avais probablement fait autre chose sur le pc.

```

     Fri Jan  2 03:48:59 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 5 hours, 49 minutes and 58 seconds.

     Sun Jan 11 04:16:09 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 5 hours, 50 minutes and 27 seconds.

     Thu Feb 12 12:09:21 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 7 hours, 4 minutes and 47 seconds.

     Fri Feb 20 07:36:28 2015 >>> app-office/libreoffice-4.4.0.3

       merge time: 7 hours, 56 minutes and 31 seconds.

     Sat Mar 14 07:04:28 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 7 hours, 56 minutes and 43 seconds.

```

Je suis repassé en binaire j'en ai ras le bol...

----------

## xaviermiller

Les temps de compilation de libreoffice sont atrocement lents, sans compter qu'en instable, libreoffice est régulièrement reconstruit, à cause de dépendances.

Malheureusement, le binaire n'est pas toujours compatible avec les libs instables  :Sad: 

----------

## kopp

Ouais, c'est pour ça que j'avais abandonné la version binaire, mais là... c'est devenu insupportable. J'ai le temps de dormir sans que ce soit fini...

Bref, j'y reviendrais peut-être quand j'aurais autre chose qu'un portable d'une autre époque

----------

## boozo

 *k-root wrote:*   

> 
> 
> ```
>      Tue Aug 26 23:35:32 2014 >>> app-office/libreoffice-4.2.6.2
> 
> ...

 

Juste une question au passage :

ici via les données de k-root,en même pas 1 an, le temps de compil à pris une sacré d'inflation   :Shocked:  !

Est-ce que cette "évolution" est directement corrélable au nombre de ligne de code ou à l'ajout de fonctionnalité par exemple ? Ils ont mis 20 devs de plus dessus à temps plein ou tout réécrit dans un autre langage ou qqch de vraiment lourd dans le genre ?  :Rolling Eyes: 

----------

## sebB

 *Quote:*   

> ici via les données de k-root,en même pas 1 an, le temps de compil à pris une sacré d'inflation

 

M'en parle pas, je me suis pris 6h d'un coup.

Va quand même falloir que j'investigue.

Si je prends vos chiffres, la compil de libreoffice 4.3 mettait 2h moins de temps chez moi que chez certains.

Avec libreoffice 4.4, je mets 1h30 de plus que vous.

----------

## Leander256

Il y a peut-être un changement de version de gcc qui est passé par là aussi? Il me semble que sur le long terme gcc a eu tendance à améliorer son optimisation du C++ au détriment du temps de compilation.

----------

## SwordArMor

Ça devient également de plus en plus critique sur mon laptop :

```
$ genlop -t libreoffice

 * app-office/libreoffice

     Wed Oct 29 22:33:56 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 4 hours, 16 minutes and 46 seconds.

     Fri Nov  7 19:20:09 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 4 hours, 35 minutes and 44 seconds.

     Tue Nov 18 04:32:23 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 4 hours, 34 minutes.

     Sun Jan  4 20:15:36 2015 >>> app-office/libreoffice-4.2.8.2

       merge time: 5 hours, 21 minutes and 36 seconds.

     Tue Feb 17 04:27:05 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 5 hours, 52 minutes and 42 seconds.

     Mon Mar  9 08:38:01 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 5 hours, 54 minutes and 4 seconds.

     Tue Apr  7 23:33:41 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 7 hours, 1 minute and 50 seconds.

     Tue Apr 14 03:28:08 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 7 hours, 1 minute and 50 seconds.

```

J’ai un Core2Duo L9400 dessus.

J’ai aussi failli passer sur la version binaire à la dernière mise à jour, mais à cause du temps de compilation. Il m’a fallu près de 10 Go de libre dans mon /var/tmp/ pour compiler, j’ai donc dû faire du ménage pour que ça passe.

----------

## ghoti

Eh bé moi qui pensais que mon Core2Duo E8400 @4GHz commençait à dater, il semblerait que je ne suis pas encore tout à fait largué, finalement !   :Cool: 

Même si, comme chez tout le monde, un sérieux allongement est à déplorer ...

```
genlop -t libreoffice

 * app-office/libreoffice

     Thu Oct 30 18:13:36 2014 >>> app-office/libreoffice-4.3.1.2

       merge time: 2 hours, 56 minutes and 56 seconds.

     Sun Dec 28 23:31:18 2014 >>> app-office/libreoffice-4.3.5.2

       merge time: 2 hours, 55 minutes and 4 seconds.

     Sat Jan  3 22:50:33 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 2 hours, 35 minutes and 4 seconds.

     Fri Feb 27 16:48:53 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 3 hours, 39 minutes and 12 seconds.

     Sat Mar 14 16:09:02 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 4 hours, 9 minutes and 33 seconds.

     Mon Apr  6 00:21:39 2015 >>> app-office/libreoffice-4.4.2.2

       merge time: 4 hours, 20 minutes and 34 seconds.
```

amd64, 8 Go de RAM et le PORTAGE_TMPDIR de libreoffice défini sur un SSD SanDisk SDSSDXPS240G.

----------

## ghoti

... et sur le PC de mon épouse (AMD Phenom II X4 965 Black @3.4Ghz, 8 Go RAM, SSD SanDisk SDSSDHP256G) :

```
genlop -t libreoffice                                                                                                           

* app-office/libreoffice

     Tue Dec 31 01:44:02 2013 >>> app-office/libreoffice-4.1.4.2

       merge time: 1 hour, 12 minutes and 11 seconds.

     Thu Feb 13 20:00:16 2014 >>> app-office/libreoffice-4.2.0.4

       merge time: 1 hour, 20 minutes and 6 seconds.

     Thu Feb 19 22:34:04 2015 >>> app-office/libreoffice-4.4.0.3

       merge time: 1 hour, 42 minutes and 8 seconds.

     Mon Mar 23 22:36:27 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 1 hour, 39 minutes and 55 seconds.

     Fri Apr 24 23:18:15 2015 >>> app-office/libreoffice-4.4.2.2

       merge time: 2 hours, 25 minutes and 12 seconds.
```

----------

## SwordArMor

 *ghoti wrote:*   

> Eh bé moi qui pensais que mon Core2Duo E8400 @4GHz commençait à dater, il semblerait que je ne suis pas encore tout à fait largué, finalement !  
> 
> 

 

Ce bon vieux X200 est tellement bien que je n’ai pas envie de le changer pour une bête histoire de CPU. Ce n’est que lorsque je compile que je sens que je suis sur un Core2Duo.

Du coup j’ai trouvé une parade très simple, une fois par semaine je le laisse faire ses mises à jour comme un grand pendant que je dors et je ne m’en rends plus compte.

Par contre, si je regarde sur mon PC fixe j’ai des temps similaires à ceux de ton épouse mais toujours en forte augmentation. C’est un i7 930 là.

```
alarig@airmure ~ $ genlop -t libreoffice

 * app-office/libreoffice

     Sat May 17 00:40:01 2014 >>> app-office/libreoffice-4.1.4.2

       merge time: 1 hour, 11 minutes and 46 seconds.

     Sun Jul 27 02:06:09 2014 >>> app-office/libreoffice-4.2.5.2

       merge time: 1 hour, 27 minutes and 57 seconds.

     Sun Jul 27 12:33:54 2014 >>> app-office/libreoffice-4.2.5.2

       merge time: 1 hour, 28 minutes and 14 seconds.

     Sun Sep 21 13:03:46 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 1 hour, 29 minutes and 7 seconds.

     Thu Nov  6 11:24:02 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 1 hour, 31 minutes and 7 seconds.

     Mon Nov 17 02:19:49 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 1 hour, 56 minutes and 28 seconds.

     Sun Jan  4 12:59:21 2015 >>> app-office/libreoffice-4.2.8.2

       merge time: 1 hour, 40 minutes and 47 seconds.

     Tue Feb 17 09:20:09 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 1 hour, 38 minutes and 35 seconds.

     Sun Mar  8 22:55:43 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 1 hour, 55 minutes and 4 seconds.

     Tue Apr  7 13:56:27 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 1 hour, 35 minutes and 23 seconds.

     Mon Apr 13 15:52:35 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 2 hours, 4 minutes and 9 seconds.

```

----------

## xaviermiller

@ghoti, quelle version de GCC utilises-tu ? et les USE flags pour libreoffice ?

----------

## ghoti

Pour l'instant, j'utilise gcc-4.9.2 sur les deux plateformes.

En général, j'utilise les versions instables les plus récentes dans le slot le plus élevé.

Pour les flags :

- sur le Core2Duo : 

```
emerge libreoffice -pv

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] app-office/libreoffice-4.4.2.2::gentoo  USE="bluetooth branding cups dbus gtk kde mysql (-aqua) -coinmp -collada -debug -eds (-firebird) -gltf -gnome -gstreamer -gtk3 -java -jemalloc -odk -postgres -telepathy {-test} -vlc" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 0 KiB
```

Sur le Phenom II :

```
emerge libreoffice -pv

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] app-office/libreoffice-4.4.2.2::gentoo  USE="branding cups dbus java kde (-aqua) -bluetooth -coinmp -collada -debug -eds (-firebird) -gltf -gnome -gstreamer -gtk -gtk3 -jemalloc -mysql -odk -postgres -telepathy {-test} -vlc" LIBREOFFICE_EXTENSIONS="nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 0 KiB

```

----------

## xaviermiller

et les CFLAGS ?

----------

## ghoti

 *xaviermiller wrote:*   

> et les CFLAGS ?

 

Rien de bien méchant :

Core2Duo :

```
emerge --info |grep -i flags

CFLAGS="-march=native -O2 -pipe"

CXXFLAGS="-march=native -O2 -pipe"

FCFLAGS="-O2 -pipe"

FFLAGS="-O2 -pipe"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

USE="X a52 aac acl acpi alsa amd64 bash-completion bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus declarative dri dts dvd dvdr emboss encode exif fam firefox flac fortran gif glamor gpm gtk iconv jpeg jpeg2k kde kipi lcms ldap libnotify mad mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses networkmanager nls nptl nsplugin nvidia ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds qt3support qt4 readline sdl session smp spell sqlite sse sse2 sse4_1 ssl ssse3 startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vdpau vorbis wxwidgets x264 xcb xcomposite xinerama xml xscreensaver xv xvid zeroconf zlib" ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 sse4_1 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

```

Phenom II :

```
emerge --info |grep -i flags

CFLAGS="-march=native -O2 -pipe"

CXXFLAGS="-march=native -O2 -pipe"

FCFLAGS="-O2 -pipe"

FFLAGS="-O2 -pipe"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

USE="X a52 aac acl acpi alsa amd64 branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus declarative dri dts dvd dvdr emboss encode exif fam firefox flac fortran gif glamor gpm gtk iconv jpeg jpeg2k kde kipi lcms ldap libnotify mad mmx mmxext mng modules mp3 mp4 mpeg multilib ncurses networkmanager nls nptl nsplugin ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds qt3support qt4 readline sdl session spell sqlite sse sse2 sse3 ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext popcnt sse sse2 sse3 sse4a" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON                                                                                                                              
```

----------

## sebB

Je pensais que c'était mon i7 Q 720 @ 1.60GHz qui faiblissait mais à la vue de vos stats je pencherais plus pour augmenter ma ram

Va falloir que j'investisse dans des barrettes car mes 4 Go deviennent limite.

Mon portable swappe des les 1ere secondes de compil et devient inutilisable.

@Leander256: Effectivement je suis passé de gcc 4.8.3  a gcc 4.8.4 mais je pense pas que le probleme vienne de là.

@k-root:kopp Pouvez-vous donner votre proc et la quantité de ram?

----------

## kopp

Moi j'ai une machine qui date d'une autre époque, Core 2 Duo T7200, et 2G de RAM.

C'est de plus en plus limite, même pour firefox..

ça fait longtemps que je ne peux plus compiler pas mal de chose en tmpfs.

----------

## DuF

Histoire d'apporter un peu plus de statistiques : 

```

genduf ~ # genlop -t libreoffice 

 * app-office/libreoffice

     Thu Jan 23 21:15:01 2014 >>> app-office/libreoffice-4.1.3.2-r2

       merge time: 52 minutes and 1 second.

     Mon Jan 27 23:14:57 2014 >>> app-office/libreoffice-4.1.3.2-r2

       merge time: 51 minutes and 5 seconds.

     Mon Feb 10 23:17:40 2014 >>> app-office/libreoffice-4.1.4.2

       merge time: 51 minutes and 18 seconds.

     Mon May 26 20:07:33 2014 >>> app-office/libreoffice-4.1.4.2

       merge time: 1 hour, 10 minutes and 21 seconds.

     Thu Jun 12 23:30:34 2014 >>> app-office/libreoffice-4.2.3.3-r1

       merge time: 1 hour, 36 minutes and 35 seconds.

     Sat Jul 12 15:51:54 2014 >>> app-office/libreoffice-4.2.5.2

       merge time: 59 minutes and 48 seconds.

     Sat Sep 20 17:38:14 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 1 hour, 4 minutes and 55 seconds.

     Mon Nov 17 21:47:00 2014 >>> app-office/libreoffice-4.2.6.3

       merge time: 1 hour, 7 minutes and 42 seconds.

     Sun Jan  4 19:09:58 2015 >>> app-office/libreoffice-4.2.8.2

       merge time: 1 hour, 6 minutes and 22 seconds.

     Sun Mar  1 20:26:37 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 1 hour, 9 minutes and 15 seconds.

     Wed Apr  8 23:38:19 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 1 hour, 9 minutes and 42 seconds.

     Sat Apr 18 16:28:25 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 1 hour, 22 minutes and 34 seconds.

```

Les 2 temps bien différents de la version 4.1.4.2 (pratiquement 40% d'écart) me font penser qu'il peut y avoir des fois soit un impact fort de GCC soit d'un USE qui viendrait pourrir le truc.

Après entre la 4.2.3.3-r1 et la 4.2.5.2 c'est là ou j'ai augmenté ma ram (question de cohérence avec le couple ssd+gentoo, me suis dit que c'était le moyen le plus simple d'avoir un gros tmpfs en ram  :Very Happy:  ).

Sinon mon système de 2012 sauf ajout de ram mi-2014 (tiens du coup je vois que ça fait longtemps que je suis en mode flemme pour changer de noyau, va falloir que je me bouge) : 

```
Portage 2.2.18 (python 3.3.5-final-0, default/linux/amd64/13.0/desktop/gnome/systemd, gcc-4.8.4, glibc-2.20-r2, 3.10.25-gentoo x86_64)

=================================================================

System uname: Linux-3.10.25-gentoo-x86_64-Intel-R-_Core-TM-_i7-3770_CPU_3.40GHz-with-gentoo-2.2

KiB Mem:    32670316 total,    380472 free

KiB Swap:     524284 total,    520540 free

(...)

CFLAGS="-march=native -O2 -pipe"

CXXFLAGS="-march=native -O2 -pipe"

FCFLAGS="-O2 -pipe"

FFLAGS="-O2 -pipe"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

```

----------

## kopp

ça a l'air bien quand même, une machine moderne   :Rolling Eyes: 

----------

## redjack1964

 *kopp wrote:*   

> ça a l'air bien quand même, une machine moderne  

 

C'est le pied   :Cool:  !

Mais pourquoi tu n'investis pas dans du matériel récent? 

Les prix restent abordable.

----------

## kopp

Parce que dans deux ans, il sera vieux :p

Tant que ça marche, je change pas ... ce n'est pas encore la mort, et quand je vois les pc bien plus récent mais bas de gamme de certains proches, mon vieux machin est encore pas mal (ou alors c'est l'OS ....   :Evil or Very Mad:  )

----------

## xaviermiller

+1 ! Je ne vais pas remplacer mes machines qui ont 8 ans et qui ronronnent encore parfaitement tout en répondant présent pour les attributions données  :Wink: 

----------

## SwordArMor

Je suis aussi de cette école. Ma machine la plus ancienne a quinze ans et elle commence tout juste à montrer quelques signes de fatigue.

----------

## DuF

moi je n'ai pas eu le choix, mon alimentation avait grillé (ça fait toujours bizarre une fumée qui s'échappe avec une odeur de plastique fondue) et avait en même temps grillé des composants de la carte mère. Du coup j'avais pris une configuration adaptée à mon usage (puissante brute mais carte vidéo de base).

Mais pareil les composants ont 3 ans et je ne pense pas changer dans les années à venir (si possible minimum une décennie  :Smile:  ) et j'espère que libreoffice n'augmentera pas ses besoins  :Smile: 

----------

## xaviermiller

Il y a des alternatives à libreoffice telles abiword et gnumeric, mais pour du "powerpoint", je ne vois pas trop. Et libreoffice est moins médiocre comparé aux sus-nommés concernant la compatibilité avec MS Office.

----------

## Leander256

Il faut dire que la puissance de calcul nécessaire pour la plupart des tâches courantes est largement suffisante depuis quelques années. Et quand une tâche prenait du temps, c'était assez souvent à cause du disque dur, je pense que tous les gens qui ont fait l'expérience d'une transition HDD -> SSD sur une même machine comprendront très bien de quoi je veux parler!

D'ailleurs pour en revenir au sujet quelqu'un l'a déjà mentionné mais maintenant ça me paraît évident, si le temps de compilation de libreoffice fait un bond très brusque, c'est très probablement lié à l'utilisation de la swap. Et là encore on peut mettre en cause GCC qui peut prendre des tonnes de mémoire pour compiler certains bouts de C++. Je n'ai rien contre GCC, soit dit en passant!

 *Quote:*   

> Il y a des alternatives à libreoffice telles abiword et gnumeric, mais pour du "powerpoint", je ne vois pas trop. Et libreoffice est moins médiocre comparé aux sus-nommés concernant la compatibilité avec MS Office.

 

Peut-être Calligra? Je n'ai pas vraiment eu l'occasion de m'en servir jusqu'à présent, mais cette suite me semble intéressante. Bon par contre c'est du KDE, ce n'est pas forcément plus léger à compiler  :Laughing: 

----------

## 341438

@DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé

à combien de ram ?

----------

## sebB

Effectivement je suis en train de me tater pour repasser sous calligra (qui de mémoire gère les powerpoint).

Je pense aussi que libreoffice est devenu gourmand en mémoire mais ca n'explique pas mon écart de compil (moi je me suis pris 6h en plus d'un coup).

Surtout quand je vois que kopp avec son Core 2 et ses 2G de ram compile plus vite.

Et cette différence je ne l'ai que sur libreoffice.

----------

## kopp

 *Tristelune wrote:*   

> @DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé
> 
> à combien de ram ?

 

Il est passé à 32, c'est écrit ... de 16 je suppose.

SInon la question c'est surtout : tu compiles en tmpfs Duf ?

Sinon, pour rappel : 

```
     Tue Dec  5 21:26:28 2006 >>> app-office/openoffice-2.0.4

       merge time: 2 hours, 21 minutes and 58 seconds.
```

sur la même machine...

En même temps à l'époque Firefox (2 !) prenait entre 8 et 30 minutes... sans tmpfs. Maintenant il lui faut 2h en tmps, mais je suppose que ça swap pas mal sur ma machine ...

----------

## 341438

 *kopp wrote:*   

> 
> 
> Il est passé à 32, c'est écrit ... de 16 je suppose.
> 
> 

 

Je suis un malin, je n'ai pas eu la curiosité de regarder ce qu'il y avait dans la deuxième partie du code. 

Merci pour l'info!

----------

## DuF

 *kopp wrote:*   

>  *Tristelune wrote:*   @DuF: le temps de compilation a diminué lorsque tu as augmenté la ram. Tu es passé
> 
> à combien de ram ? 
> 
> Il est passé à 32, c'est écrit ... de 16 je suppose.
> ...

 

En fait je suis passé de 4 à 32 et je fais pointer PORTAGE_TMPDIR vers /tmp qui est un tmpfs.

Pour firefox sinon, depuis le début de l'année ça s'est drôlement amélioré chez moi : 

 *Quote:*   

>      Thu Jan 15 20:03:21 2015 >>> www-client/firefox-35.0
> 
>        merge time: 26 minutes and 31 seconds.
> 
>      Fri Feb 27 23:27:43 2015 >>> www-client/firefox-36.0
> ...

 

----------

## xaviermiller

La dernière mouture a pris 18h sur mon atom, contre 6-7 heures il y a quelques mois... via distcc à chaque fois   :Shocked: 

----------

## sebB

```
Sun Feb 15 20:56:34 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 3 hours, 10 minutes and 44 seconds.

Sun Apr 19 18:47:34 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 8 hours, 41 minutes and 59 seconds.

Wen May 27 20:11:56 2015 >>> app-office/libreoffice-4.4.3.2

       merge time: 5 hours, 52 minutes and 38 seconds.
```

Bon ca s'améliore avec les versions.

Je retombe un peu dans la moyenne à la vue de vos stats.

A croire que la version 4.4.1.2 avait un soucis chez moi.

----------

## SwordArMor

Tu n’es pas le seul à avoir une temps de compilation plus long pour la 4.4.1.2 :

```
     Tue Apr  7 13:56:27 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 1 hour, 35 minutes and 23 seconds.

     Mon Apr 13 15:52:35 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 2 hours, 4 minutes and 9 seconds.

```

----------

## augustin

```
 

Victoria config # genlop -t libreoffice 

 * app-office/libreoffice

                                                                                                                                                                            

     Wed Mar  4 22:38:50 2015 >>> app-office/libreoffice-4.3.5.2                                                                                                            

       merge time: 2 hours, 10 minutes and 43 seconds.                                                                                                                      

     Thu Mar  5 04:34:54 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 3 hours, 22 minutes and 47 seconds.                                                                                                                      

     Fri Apr 17 19:23:28 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 2 hours, 23 minutes and 33 seconds.                                                                                                                      

     Thu May 28 10:38:32 2015 >>> app-office/libreoffice-4.4.3.2

       merge time: 2 hours, 56 minutes and 5 seconds.                                                                                                                       

```

AMD Phenom(tm) II X4 955 Processor

----------

## DuF

```
     Wed Apr  8 23:38:19 2015 >>> app-office/libreoffice-4.3.5.2

       merge time: 1 hour, 9 minutes and 42 seconds.

     Sat Apr 18 16:28:25 2015 >>> app-office/libreoffice-4.4.1.2

       merge time: 1 hour, 22 minutes and 34 seconds.

     Sat May 30 16:58:33 2015 >>> app-office/libreoffice-4.4.3.2

       merge time: 1 hour, 26 minutes and 33 seconds.

```

On ne compile pas tous la même chose ni avec les mêmes éléments (gcc-4.8.4 chez moi)

----------

## sebB

Y'a t'il un moyen de gérer les accés disque lors de la compil de libreoffice?

Mon load average grimpe à 12/13 alors que dans mon make.conf je l'ai limité à 8.

On peut voir que ce n'est pas la charge de mes cpu qui coince.

Mon disque est en activité constante et mon ordi inutilisable pendant 8h car il rame.

Y'a-t-il mieux que ext4 pour compiler si le probleme vient de là?

Certe je peux lancer les compil la nuit mais j'aimerais bien comprendre.

Stats compil libreoffice.

top

```
1 user,  load average: 7,93, 8,83, 8,81

Tasks: 237 total,   2 running, 235 sleeping,   0 stopped,   0 zombie

%Cpu(s):  0,1 us,  3,0 sy, 60,1 ni,  8,1 id, 28,6 wa,  0,0 hi,  0,1 si,  0,0 st

KiB Mem:   3967952 total,  3878408 used,    89544 free,      496 buffers

KiB Swap:  8388604 total,  1629216 used,  6759388 free.    24144 cached Mem
```

iostat

```
avg-cpu:  %user   %nice %system %iowait  %steal   %idle

           0,13    0,75    0,25   22,43    0,00   76,44

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util

sda              19,00     0,00  146,00    2,00  2608,00   888,00    47,24    21,16  969,47  890,53 6732,00   6,76 100,00

dm-0              0,00     0,00   42,00    0,00  2220,00     0,00   105,71     9,15 1565,69 1565,69    0,00  23,81 100,00

dm-1              0,00     0,00  122,00    0,00   488,00     0,00     8,00    76,33 12846,57  596,30    0,00   8,20 100,00

dm-2              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

dm-3              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00

dm-4              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00    0,00    0,00   0,00   0,00
```

iostat -x 1

```
avg-cpu:  %user   %nice %system %iowait  %steal   %idle

           2,01   38,98    2,95   14,05    0,00   42,00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

sda              33,81       315,53       695,21   22248798   49020176

dm-0              6,71       126,08         8,05    8890125     567352

dm-1            177,07       134,22       574,06    9463756   40477876

dm-2             13,89        46,00        74,63    3243573    5262580

dm-3              0,90         8,78        12,77     618901     900328

dm-4              5,66         0,41        25,70      29257    1811868
```

make.conf

```
CHOST="x86_64-pc-linux-gnu"

CFLAGS="-O2 -march=native -pipe"

CXXFLAGS="${CFLAGS}"

MAKEOPTS="-j9 -l8"

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="*"

EMERGE_DEFAULT_OPTS="--jobs=4 --load-average=4.0 --keep-going --with-bdeps=y"

PORTAGE_ELOG_CLASSES="log warn error info"

PORTAGE_ELOG_SYSTEM="echo:log,warn save:log,warn,error,info syslog:error"

PORTAGE_NICENESS=19

PORTAGE_IONICE_COMMAND="ionice -c 3 -p \${PID}"
```

----------

## El_Goretto

 *sebB wrote:*   

> Y'a t'il un moyen de gérer les accés disque lors de la compil de libreoffice?
> 
> Mon load average grimpe à 12/13 alors que dans mon make.conf je l'ai limité à 8.
> 
> [...]
> ...

 

Tel que je vois les choses, tu as un poil trop trituré ta configuration portage (classique et chronique pour un utilisateur gentoo) et tu as fini par faire du "ricing"  :Smile: 

4 fois 9 threads n'est peut être pas ce que tu attendais, mais c'est ce que tu as configuré.

man emerge:

 *Quote:*   

>        -j [JOBS], --jobs[=JOBS]
> 
>               Specifies  the  number  of  packages to build simultaneously.

 

Donc 4 packages en parallèle, avec chacun 9 threads... Ca pourrait peut être venir de là. Le disque n'est pas le tueur, mais une victime  :Wink: 

J'aime bien ton idée de jouer avec une limite de load, mais si jamais tu as une machine qui n'est pas un desktop et a une charge CPU non nulle en dehors de l'activité de portage, tu risques d'avoir des temps de compilation/emerge assez lamentables.

Ce que j'essaierais: si tu  souhaites rester à jouer avec le load limit, ne garde que la config MAKEOPTS qui s'applique à chaque package. Et si tu as une machine ayant des traitements CPU constants (un serveur par exemple), garde uniquement le PORTAGE_NICENESS en retirant les load-limit (si tu considères qu'une MAJ doit être traitée en un temps raisonnable). Mais bon, c'est peut être un poil moins fun, je te l'accorde, libre à toi de rechercher une combinaison plus amusante.  :Smile: 

----------

## sebB

Effectivement j'ai fais pas mal de test, et certains trucs ont été ajoutés car c'était la mode....

Je ne savais pas que que les threads se multipliaient avec les packages.

Je pensais:

 *Quote:*   

> MAKEOPTS, dans mon cas maxi 9 threads et limite load à 8
> 
> EMERGE_DEFAULT_OPTS, on dit au package suivant de démarer si 1 threads est libre et que le load est inférieur à 4.
> 
> D'ou paquet A utilise 6 threads et load < 4 donc paquet B demarre avec les 3 threads qui sont dispo.
> ...

 

Je viens de faire un tas de tests notamment avec gcc 4.9.3 et aucune issue avec libreoffice.

firefox + thunderbird sont passés sans probleme (aucun freeze).

J'ai juste laissé dans mon make.conf, MAKEOPTS=j(n)

Je viens de me rendre compte qu'un autre paquet à les mêmes "symptomes", sigil.

Avec un j>4 mon systeme ne répond plus et le load grimpe à 15 même si je tente de le limiter (d'ailleurs ca semble pas marcher ce -jn -ln). Celui là en plus est compilé en tmpfs.

Si je stoppe la compil, la diode de mon dd reste allumée et mon systeme est inutilisable (rien dans top) même après un rm du tmp. Ca revient à la normale au but de 5 minutes.

```
Mon Nov 17 23:20:42 2014 >>> app-text/sigil-0.6.2 

       merge time: 7 minutes and 28 seconds.

Tue Dec 30 09:51:14 2014 >>> app-text/sigil-0.6.2

       merge time: 6 minutes and 53 seconds.

Mon Jul 20 00:58:19 2015 >>> app-text/sigil-0.6.2

       merge time: 33 minutes and 1 second.
```

top

```
1 user,  load average: 14,67, 11,14, 8,07

Tasks: 234 total,  10 running, 224 sleeping,   0 stopped,   0 zombie

%Cpu(s): 98,8 us,  1,2 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st

KiB Mem:   3967952 total,  3518376 used,   449576 free,   143488 buffers

KiB Swap:  8388604 total,     2664 used,  8385940 free.  1249752 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     

10809 portage   20   0  412556 384896  17040 R  95,9  9,7   3:16.67 cc1plus     

11704 portage   20   0  111352  84740  17308 R  93,2  2,1   0:06.23 cc1plus     

11680 portage   20   0  127032 101408  17308 R  86,9  2,6   0:10.82 cc1plus     

11712 portage   20   0  111600  85304  17388 R  86,6  2,1   0:05.65 cc1plus     

11696 portage   20   0  111624  87020  17264 R  82,6  2,2   0:06.60 cc1plus     

11708 portage   20   0  113972  88940  17308 R  82,3  2,2   0:05.72 cc1plus     

11664 portage   20   0  138428 114044  17380 R  79,9  2,9   0:12.91 cc1plus     

11721 portage   20   0   96960  67676  14072 R  75,0  1,7   0:02.26 cc1plus     

11725 portage   20   0   85776  54336  12160 R  45,8  1,4   0:01.38 cc1plus    
```

Je suis en train de réinstaller gcc 4.7 pour voir. Après je seche.

Au pire je regarderais si y'a pas moyen de passer un -jn a certains paquets dans le package.env

EDIT: gcc 4.7 ne résoud rien. J'ai donc créé un fichier j4.conf en attendant mieux.

----------

## El_Goretto

 *sebB wrote:*   

> J'ai juste laissé dans mon make.conf, MAKEOPTS=j(n)
> 
> 

 

Sage décision, mieux vaut repartir de 0 et rajouter petit à petit d'éventuels tunings.

 *sebB wrote:*   

> Je viens de me rendre compte qu'un autre paquet à les mêmes "symptomes", sigil.
> 
> Avec un j>4 mon systeme ne répond plus et le load grimpe à 15 même si je tente de le limiter (d'ailleurs ca semble pas marcher ce -jn -ln). Celui là en plus est compilé en tmpfs.
> 
> Si je stoppe la compil, la diode de mon dd reste allumée et mon systeme est inutilisable (rien dans top) même après un rm du tmp. Ca revient à la normale au but de 5 minutes.

 

J'allais dire: cela ressemble fichtrement aus symptômes d'une machine qui swape comme une malheureuse. Et tes différents "screenshots" de top tendent à le prouver. Il va peut être falloir refaire le tour de tes différents montages tmpfs si tu en as, voire redevenir humble du côté de ce que tu demandes à ta machine  :Smile: 

Pour rappel, on parle quand même de la compilation d'un paquet obèse de chez obèse, OpenOffice  :Smile: 

----------

## sebB

Après plusieurs test, j'ai des paquets qui ne passe plus avec un j>4 alors qu'avant aucun soucis.

Si pour libreoffice je suis ok, pour sigil je comprends pas.

En même temps je vais rester en j4 car je ne perds que 10 min sur les grosses compil comparé à mon j9.

Par contre es tu sur de ca?

 *Quote:*   

> Tel que je vois les choses, tu as un poil trop trituré ta configuration portage (classique et chronique pour un utilisateur gentoo) et tu as fini par faire du "ricing" 
> 
> 4 fois 9 threads n'est peut être pas ce que tu attendais, mais c'est ce que tu as configuré. 

 

Car moi je pensais

MAKEOPTS=-j9, dans mon cas maxi 9 threads

EMERGE_DEFAULT_OPTS=--jobs=4 --load-average=4, on dit au package suivant de démarer si 1 threads est libre et que le load est inférieur à 4.

J'en déduisait que si paquet A utilise 6 threads et load < 4 donc paquet B demarre avec les 3 threads qui sont dispo.

----------

## kopp

Pour moi, le MAKEOPTS ne concerne qu'un seul paquet à la fois, pas une option globale.

Tu n'auras peut-être pas 4 paquets en même temps à 9 threads, mais c'est possible qu'il y en ait plusieurs quand même.

----------

