Aller plus loin
- Openoffice.org (3 clics)
- RC3 en fr (11 clics)
- "features" (3 clics)
Openoffice.org 1.1 RC3
18
août
2003
Depuis le 14 août, OOo RC3 est disponible au téléchargement. C'est la fin de la ligne droite pour cette nouvelle version qui apporte de réels progrès comme : l'export pdf et flash, l'utilisation "sans souris", l'écriture verticale, l'enregistrement des macros, et bien sûr MS Office compatibility enhancements et "The splash screen now has a progress bar". 1.1 RC3 disponible en version fr !
# Re: Openoffice.org RC3
Posté par Cédric Chantepie . Évalué à 5.
[^] # Re: Openoffice.org RC3
Posté par Patrix (site web personnel) . Évalué à 4.
/l'exports/l'export/
/enregisrement/enregistrement/
[^] # Re: Openoffice.org RC3
Posté par mac . Évalué à 5.
puis y a un unmatched "
Au fait, il n'y a pas de correcteur d'orthographe sous OOo RC3 ? :)
[^] # Re: Openoffice.org RC3
Posté par xmoucheron . Évalué à 5.
Tu peux le trouver ici:
http://sourceforge.net/projects/ooodi/(...)
[^] # Re: Openoffice.org RC3
Posté par xmoucheron . Évalué à 1.
mais openoffice 1.1 rc3 ne l'utilise pas. Que dois-je faire pour profiter du correcteur d'orthographe français?
[^] # Re: Openoffice.org RC3
Posté par xmoucheron . Évalué à 2.
http://lingucomponent.openoffice.org/download_dictionary.html(...)
et de le décompresser dans .../openoffice/share/dic
# Re: Openoffice.org RC3
Posté par Gawan . Évalué à 5.
Quelles sont les réels ajouts de OOo RC3 ?
[^] # Re: Openoffice.org RC3
Posté par Nim . Évalué à 6.
C'est essentiellement de la correction de bogues.
[^] # Re: Openoffice.org RC3
Posté par Nap . Évalué à 2.
[^] # Re: Openoffice.org RC3
Posté par zyglotron . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par jies . Évalué à -1.
Je note quand même que la version française est disponible, et que l'export pdf peut se faire en 3 qualités différentes choses qui (mais je ne suis pas sur) ne pouvaient pas se faire avec la RC1.
[^] # Re: Openoffice.org RC3
Posté par lionel tricon . Évalué à 4.
# Re: Openoffice.org RC3
Posté par Axel R. (site web personnel) . Évalué à 2.
En général, l'équipe de traduction a un peu de retard (ce sont des perfectionnistes et je ne saurais que trop saluer leur excellent travail !)
Axel
[^] # Re: Openoffice.org RC3
Posté par Serge2 . Évalué à 3.
Exemple:
http://ftp.club-internet.fr/pub/OpenOffice/contrib/rc/1.1rc3/(...)
[^] # Re: Openoffice.org RC3
Posté par vga1523 . Évalué à 2.
tank U !!
je m'interroge, quelle va être l'excuse des administartions françaises pour garder MSOffice ?
nous le sauront au prochain épisode.....
(ça m'énerve de savoir qu'une partie des impôts vont dans la poche à billou)
moinssez ! moinssez ! c'est l'époque de la moisson !!
[^] # Re: Openoffice.org RC3
Posté par TyrandO . Évalué à 2.
Ah ces citadins coupés de leurs racines ...
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 4.
Bein forcement qu'il sont coupés de leurs racines si ils ont été moissonés y'a trois semaines.
...
....
->[]
[^] # Re: Openoffice.org RC3
Posté par François Schoubben (site web personnel) . Évalué à 4.
Pour ma part, j'habite à côté d'un silo à grain... Je peux dire exactement les jours de moisson... C'est quand je peux dormir de 4 à 6 h du mat avec des boules quiès :-)
[^] # Re: Openoffice.org RC3
Posté par MrTout (site web personnel) . Évalué à 1.
Manque pas une négation ou un "seulement" dedans ? sinon avec un tel raisonement demain est potentiellement un jour de moisson.
[^] # Re: Openoffice.org RC3
Posté par Zorro (site web personnel) . Évalué à -1.
[^] # Re: Openoffice.org RC3
Posté par vga1523 . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par aegir_lf . Évalué à 2.
Le problème (ou "l'excuse" selon ta terminologie), c'est la compatibilité des documents existants au format MS avec OO.
Parce que même si 99% des documents MS ne posent pas de problème de récupération sous OO, je te laisse imaginer la masse que représente les 1% restant dans une administration comme Bercy...
[^] # Re: Openoffice.org RC3
Posté par vga1523 . Évalué à 1.
car pour moi Bercy --> DREE et donc full microsoft (et je sais de koi je parles, je suis en plein dedan)
donc une preuve m'aiderais dans mon lobbying pro-linux.
[^] # Re: Openoffice.org RC3
Posté par herve . Évalué à 1.
OOo à la DGDDI c'est en cours. (cf mon post plus bas).
Des formations seront même assurée aux nouvelles promos d'agents....
[^] # Re: Openoffice.org RC3
Posté par peau chat . Évalué à 1.
Depuis 6-8 mois à peu près, il se passe des choses «souterraines» dans l'administration. Quand je dis souterraines, je veux dire qu'ils mette de plus en plus de libre (suite à des instructions qui viennent «d'en haut»), mais aucune publicité n'est faite là dessus. J'ai même entendu parler de cas où ils continuaient à payer les licences microsoft. Je n'ai pas vraiment de certitudes, c'est soit par incompétence (c'est possible) voire comme le prétendent d'autre «pour pas que cela se sache».
On pourrait croire que l'administration essaye en catimini d'atteindre une masse critique avant de frapper fort. C'est une supposition de ma part, mais quelques témoignages directs que j'ai reçus me le font croire.
Un exemple : Bull présentait à la Linux Expo des solutions «clef en main» de serveur sous linux avec Apache, PHP, MySQL, Sendmail, SPIP etc.
Les gars de Bull avec qui j'ai discutait m'ont dit que ces produits avait été créés afin de répondre à des directives ministérielles adressées à des administrations...
[^] # Re: Openoffice.org RC3
Posté par Benjamin . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par LudoX . Évalué à 1.
Donc, c'est pas forcemment aux impôts que j'aurai installé OOo en premier lieu...
[^] # Re: Openoffice.org RC3
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 3.
Fais bouger un fonctionnaire de la bureaucratie pour voir... ah ben oui, en dehors d'une manif.
[TROLL]
Dites, M. Raffarin, on gagnerait combien à mettre dix chercheurs à plein temps sur OOo et résilier toutes les licences Windows/MSOffice de la fnction publique ?
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 3.
<blockquote>Dites, M. Raffarin, on gagnerait combien à mettre dix chercheurs à plein temps sur OOo et résilier toutes les licences Windows/MSOffice de la fnction publique ?</blockquote>
[TROLL class="gauche"]
Trop cher: la peuve, les budgets de la recherche et de l'éducation ont été sacrifiés sur l'autel de la démago sécuritaire.
Ceci dit, c'est clair qu'il est plus facile de faire bouger un élu de droite qu'un fonctionaire : il suffit de lui graisser la patte (t'as entendu parler des appels d'offres de la mairie de Paris?).
[TROLL]
[^] # Re: Openoffice.org RC3
Posté par elephpant . Évalué à 1.
Question de crédibilité par rapport aux décideurs à la mentalité étriquée et à l'égo surdimensionné.
Pfff ca m'enerve !
[^] # Re: Openoffice.org RC3
Posté par LudoX . Évalué à 1.
Plus je suis payé, plus je suis efficace. Donc je suis trés efficace... ( se dit le decideur...)
Donc 80% des français sont vraiment inefficaces... :o(
[^] # Re: Openoffice.org RC3
Posté par herve . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par _Tof_ . Évalué à 3.
Par contre, je reste persuadé qu'avec un bon travail de communication auprès des gens, on peut changer les choses. Par exemple, j'ai commencé par donner le choix aux utilisateurs entre MS Office et OO.o, et bien j'ai été surpris de voir que certains à qui j'avais bien expliqué la différence entre le format propriétaire et un format libre utilisaient déjà OO.o quand il le pouvait.
2ème exemple, la personne qui s'occupe des ressources humaines m'avait demandé un logiciel pour gérer les heures du personnel. N'ayant pas trop de temps à accorder à ce type de demande, j'ai commencé par essayer de bricoler une feuille sous excel, "pour lui simplifier la vie...". En fait, j'ai jamais pu avoir des additions d'heures correctes sous excel (quand je dépsassait 24:00, j'obtenais 02/01/1900 00:00 ..). J'ai donc recommencé sous le spreadsheet de OO.o, et comme ca marche, ma RH fonctionne sous OO.o !
Et de fil en aiguille, sans vouloir forcer les gens à tout de suite passer à linux, on fait progresser le schmilblick.....
Et prime, je me suis renseigné auprés du fournisseur de la suite de logiciels compta, paie, facturation, etc..., et on m'a assuré que ca fonctionnait sous linux (non, je ne donnerais pas de nom !). Donc je pense que d'ici 2 à 3 ans, j'aurais réussi une transition en douceur vers plus de liberté.
Pour me répeter, et même si c'est difficile voire lassant, je suis persuadé qu'on peut réussir à changer les choses avec un bon travail de communication.
[^] # Re: Openoffice.org RC3
Posté par Larry Cow . Évalué à 1.
Ca serait pas Ciel par hasard? Ca m'arrangerait bien :)
[^] # Re: Openoffice.org RC3
Posté par _Tof_ . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par Christophe BAEGERT . Évalué à 1.
# Re: Openoffice.org RC3
Posté par franck (site web personnel) . Évalué à 3.
\o/ si je ne me trompe même MS-Office n'a pas cette fonctionalité !!
[^] # Re: Openoffice.org RC3
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: Openoffice.org RC3
Posté par Merlin Lenchanteur . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par Julien Borrel . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par Marc Lacoste . Évalué à 1.
(PS: sur 225Mhz!)
[^] # Re: Openoffice.org RC3
Posté par seginus . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Re: Openoffice.org RC3
Posté par arapaho . Évalué à 2.
Bien que je me serve de OO tout les jours en lieu et place de MS Office, je trouve ce point noir vraiment chiant. Je ne sais pas à quoi cela est dû et si quelqu'un pouvait me l'expliquer ou bien me diriger vers des discussions sur ce sujet, j'en serai reconnaissant.
[^] # Re: Openoffice.org RC3
Posté par billy . Évalué à 2.
pourquoi ms office est plus rapide à démarrer ? parce que ms office utilise principalement des librairies dynamiques deja chargées en mémoire par windows. oo quand à lui a ses propre librairies meme d'interface utilisateur.
[^] # Re: Openoffice.org RC3
Posté par GnunuX (site web personnel) . Évalué à 1.
50 secds avant qu'OOo soit utilisable
ca reste long
(j'ai fait prelink -a avant ... si j'ai bien compris l'utilisation de prelink je l'utilise :/)
[^] # Re: Openoffice.org RC3
Posté par undeuxtroisout . Évalué à 2.
Ça me convient et de toute façon, je ne peux pas comparer avec office, j'ai pas vu de machine windown deuis deux ans, même jamais vu XP.
De plus, je ne remarque pas de différence notable entre les binaires officiels et ceux compilés avec les options aux petits oignons pour ma machine. Mes exécutables sont juste un peu plus gros. Par exemple:
soffice.bin officiel 385108 bytes
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
soffice.bin compilé à la maison 393764 bytes
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped
Temps de compilation : 7h15
Pour les curieux:
# emerge info
Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1)
=================================================================
System uname: 2.4.20-hardened-r2 i686 AMD Athlon(tm) MP 1900+
GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo(...) http://www.ibiblio.org/pub/Linux/distributions/gentoo(...)"
CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
PORTDIR="/usr/portage"
DISTDIR="/usr/portage/distfiles"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR_OVERLAY=""
USE="x86 3dnow apm foomaticdb libg++ mad mikmod gdbm berkdb slang arts aalib tcltk guile postgres gpm pam esd gtk motif gphoto2 scanner X alsa apache2 altivec avi bindist bonobo cdr crypt cups curl dga dnd doc dvd encode faad gb gif gnome gnomedb gtk2 gtkhtml imap imlib innodb java jpeg kde lcms libwww maildir mmx mozaccess mozcalendar mozilla mozsvg mozxmlterm mpeg music mysql ncurses nls oggvorbis opengl oss pdflib perl png python qt quicktime readline ruby sdl spell sse ssl tcpd tetex tiff truetype type1 usb wmf wxwindows xml2 xmms xv xvid zlib -mozinterfaceinfo moznoirc moznocompose -svga"
COMPILER="gcc3"
CHOST="i686-pc-linux-gnu"
CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -ffast-math -z combreloc -m3dnow -msse -mmmx -frerun-cse-after-loop -frerun-loop-opt -funroll-loops"
CXXFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -ffast-math -z combreloc -m3dnow -msse -mmmx -frerun-cse-after-loop -frerun-loop-opt -funroll-loops"
ACCEPT_KEYWORDS="x86 ~x86"
MAKEOPTS="-j 6"
AUTOCLEAN="yes"
SYNC="rsync://pol/portage"
FEATURES="sandbox ccache distcc"
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 2.
Et franchement, avec les CFLAGS de tueur que t'as, plus KDE et des logiciels de bureautique ça sert pas à grand chose d'avoir une hardened Gentoo -_^.
Sinon, j'aurais voulu savoir un truc: est-ce que toi aussi tu as un lien invalide "/opt/OpenOffice.org1.0.3/program/libstdc++.so" ? (je vais faire un joli rapport de bug je crois)
[^] # Re: Openoffice.org RC3
Posté par undeuxtroisout . Évalué à 1.
132M OpenOffice.org1.1_rc/program
138M OpenOffice.org1.1RC/program
Ça fait pas grande différence.
Je n'ai pas ton problème de lien invalide et je ne l'avais pas avec la version 1.0.3 non plus.
KDE, je ne l'utilise pas. Je l'essaie de temps en temps au fur et à mesure des sorties, mais je lui préfère gnome2.2 ou xfce4 (les égouts et les couleuvres...)
Pour ce qui est du kernel, j'avais cru qu'une 2.4.20-hardened était mieux qu'une vanilla et je ne change plus. J'évite les noyaux Gentoo (trop de soucis), le 2.4.21, les 2.5.* et 2.6.* à cause de problèmes USB (mon imprimante Dymo turbowriter disparaît)
[^] # Re: Openoffice.org RC3
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
Enfin d'un autre coté, c'est un bon test pour voir si OpenOffice est programmé proprement, avec la ceinture et les bretelles ou si il y a quelques points faibles !
;-)
Mathias
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 2.
"-O -O1 -O2 -Os -mcpu -march -pipe"
D'ailleurs, pour avoir essayé sur une LFS, je peut te dire qu'OpenOffice a tendance à être _très_ récalcitrant au moment de se faire compiler.
[^] # Re: Openoffice.org RC3
Posté par GnunuX (site web personnel) . Évalué à 1.
abiword est donc mon ami ... et ca fait pas de la bonne pub pour OOo
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 1.
Et sinon, la manière conseillée de l'invoquer c'est "prelink -afmR" ("man prelink" pour plus d'info).
[^] # Re: Openoffice.org RC3
Posté par Quentin Delance . Évalué à 4.
Je sais c'est pas la meme chose mais d'un point de vue utilisateur (pas d'un point de vue entreprise), Abiword possede tout ce qu'il faut ou presque pour travailler avec des perf bien meilleures (pour le temps de chargement c'est le jour et la nuit !).
Les dev de OO sont au courant et vont continuer a travailler dessus pour la prochaine version :
http://tools.openoffice.org/releases/q-concept.html(...)
On parle notamment d'un systeme de gestion des polices specifique a OO qui fait doublon avec fontconfig et qui penalise serieusement OO au demarrage.
[^] # Re: Openoffice.org RC3
Posté par matli . Évalué à 2.
D'autre part, Abiword <=> MS Word, mais il te manque les Excels, Powerpoint,..., surtout sous Windows car je ne crois pas qu'il existe de version Windows de Gnumeric.
Quand à l'export PDF, c'est un argument suffisant pour que plein de mes collègues installent OOo sur leur poste Windows.
Moi je dis bravo et merci à l'équipe OOo
[^] # Re: Openoffice.org RC3
Posté par aegir_lf . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par Mr YouP . Évalué à 1.
[^] # Re: Openoffice.org RC3
Posté par aegir_lf . Évalué à 2.
[^] # Re: Openoffice.org RC3
Posté par crevette . Évalué à 2.
[^] # Re: Openoffice.org RC3
Posté par aegir_lf . Évalué à 2.
Dans le même genre, le compilateur d'IBM produit du bien meilleurs code PowerPC que ne le fait GCC. Pourtant les employés d'IBM qui bossent sur le compilateur "maison", participent aussi à l'amélioration du code powerPC produit par GCC, mais de leur propre aveux, la structure multi-plateforme de GCC empêche certaines optimisations poussées.
GCC est sans doute le meilleur compilateur multi-plateforme.
Le problème vient du langage. En C++, gcc produit un code peu performant à cause de son système de v-tables (d'où le fameux objprelink ), mais en C gcc produit un binaire tout à fait correct (même si les compilateurs spécifiques à une plateforme conçus par les fondeurs de microprocesseurs sont un peu meilleurs).
[^] # Re: Openoffice.org RC3
Posté par aegir_lf . Évalué à 2.
Le problème n'est pas le C++, mais la façon dont GCC le traite.
[^] # Re: Openoffice.org RC3
Posté par MrTout (site web personnel) . Évalué à 5.
À l'époque il fut pensé de façon à optimiser les performances même si cela devait nuire aux concepts objets (les fonctions pas virtuelles par défaut, héritage répété par défaut, types primitifs non objet, contravairance, etc.). Malheureusement de nos jours les techniques ont fait beaucoup de progrès et on a à un résultat inverse : on arrive mieux à prédire un langage qui a un modèle de représentation mieu foutu.
OCaml et SmartEiffel génèrent souvent du code bien plus rapide que l'équivalent C++.
Mais bon, il ne faut pas confondre langage et compilateur. Des compilos Eiffel qui rââment on en trouve aussi :)
[^] # Re: Openoffice.org RC3
Posté par Philip Marlowe . Évalué à 1.
Les deux compilos Eiffel les plus courants, le libre et même GPL SmartEiffel ainsi que le propriétaire EiffelStudio ne rament pas. Les autres (VisualEiffel, Halstenbach), c'est le silence radio...
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 1.
Et pis troller c'est mal© de toutes manières.
[^] # Re: Openoffice.org RC3
Posté par peau chat . Évalué à 2.
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 3.
Ça à rien à voir avec le compilo.
Pour en revenir au compilo, et comme beaucoup l'ont dit: les perfs c'est bien, mais faut voir si c'est stable. Je suis sûr qu'avec les options tueuses de GCC on peut arriver à faire quelque chose du niveau de icc. Personnelement, je ne les emploie pas, parceque la fiablité est plus importante à mes yeux.
D'ailleurs, il semble que ce qui fasse la réputation de gcc aujourd'hui, c'est la conjugaison de performances satisfaisantes et d'une excelente fiabilité.
(et puis oo c'est déjà la merde pour lui faire admettre ton désir de le compiler, alors si en plus il faut le faire avec un compilateur non standard...)
[^] # Re: Openoffice.org RC3
Posté par thedidouille . Évalué à 1.
que valent les variables d'env qui influencent le comportement de ld.so ??? (du style LD_BIND_NOW) ?
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 1.
À mon humble avis, c'est plutôt un moyen de gaspiller de la RAM qu'autre chose.
Alors qu'une librairie prelinké, elle, est chargée seulement après qu'on ait essayé de l'utiliser. Mais ensuite (si j'ai bien compris), ld se fait pas chier à la localiser parce qu'elle est à un emplacement predéfini de la mèmoire (cf. la page de manuel).
[^] # Re: Openoffice.org RC3
Posté par peau chat . Évalué à 8.
Dans ce débat, il faut d'abord admettre un constat qui fait mal : Une application C++ qui utilise QT (par exemple) et compilée avec VC++ sous Windows démarrera beaucoup plus vite que la même appli sous linux compilée avec GCC.
Comme c'est pas politiquement correct de dire ça, vous allez être des dizaines à «moinsser» ou a dire «on s'en fout paske ce qui n'est pas libre c'est pas bo» etc. Mais cela ne changera rien au fait qu'un appli C++ sous linux compilée avec GCC ramera au démarrage alors que la même appli compilée avec un autre compilo sur une autre plateforme démarrera aussi vite qu'une appli «pure C».
Il y a deux explications à cela :
1) Les V-Tables. Ce sont des tables qui permettent de résoudre dynamiquement les appels à des méthodes. En POO ces tables sont nécessaires afin de résoudre lors de l'exécution les appels polymorphes. GCC ne fait pas d'optimisation à ce niveau, du coup le linker dynamique doit créer une entrée dans la table pour chacune des fois où une même méthode est héritée. Si vous avez un objet Ancetre qui a une méthode getInfo(), que cet objet est hérité par 200 autres classes, et bien la V-Table contiendra 200 entrées pour cette méthode même si ladite méthode n'est jamais surchargée par un des descendants.
Et donc, contrairement à ce que tu dis, le prelink va non seulement accélerer les choses, mais également économiser de la RAM en évitant toutes ces entrées inutiles.
2) Le C++ permettant des résolutions dynamiques, GCC et l'éditeur de liens ne s'emmerdent pas : ils ne résolvent aucun appel. Les symboles seront résolus dynamiquement au démarrage de l'application. (c'est une simplification, mais c'est l'idée générale). Alors que lors de la compilation, il est possible de résoudre l'essentiel des appels aux librairies partagées. Le format de binaires ELF permet en effet de faire un"table d'équivalence" des appels déjà résolus sur une librairie partagée, puisque cette même librairie partagée possède déjà une table de ses symboles. Donc en fait, prelink fait du boulot que l'éditeur de lien (ld) ne veut pas faire... on se demande bien pourquoi.
Depuis que le «problème» a été identifié, un certain nombres de choses ont été faites par l'équipe de dev de GCC (depuis la V3), mais on est encore loin du compte. Faut pas leur en vouloir, c'est seulement que quand on fait ce genre de modifs dans un compilo, il est préférable d'avancer prudemment ;-)
Pour info, voici ci-dessous l'analyse qu'avait faite WB à l'époque où il s'était penché sur le problème (analyse qui a donné naissance au prelink). Mais comme ça parle de KDE, C++ et surtout que ça ose supposer que le sacro-saint GNU-CC n'est pas l'ultime perfection de la galaxie (42), ce post sera sans aucun doute qualifié de «immonde troll» (ce qui est souvent bien pratique) ;-)
Aegir.
Making C++ ready for the desktop.
=================================
Author: Waldo Bastian <bastian@kde.org>
Date: May 9, 2001
Version: 1.2 (See bottom for change history)
In this paper I would like to bring the attention to an important performance
bottleneck in the ld.so linker on GNU/Linux systems wrt C++ programs. I will
try to offer some suggestions for improvement and hope that this paper will
lead to a discussion in the GNU/Linux community that eventually will lead to
a solution that addresses this problem.
It should also be noted that ld.so currently does a fine job for the things
it was designed. The problem is that it wasn't designed for todays Linux
Desktop.
This paper is based on gcc 2.95, many of the issues described here have been
fixed in gcc 3.1.
1. The symptoms
===============
Starting a KDE application from the command line is slow. Slow is a very
subjective term, but when it comes to a graphical user interface, things
are typically perceived as slow when there is a latency of more than 0.3 secs.
between action and reaction. So if I click on a button, it should bring up a
window on my screen within 0.3 secs. If it takes longer, users tend to perceive
the system as slow.
KDE is slow. Since I am very concerned about KDE I have been looking into the
reason why KDE is slow. Obviously there are a number of factors that contribute
to the problem. What we are interested in is the startup-performance which I
would like to define as the time it takes between the moment the binary image
is being executed and the moment the first visual feedback appears on the
screen.
There are 4 major contributors to the startup-performance in a KDE application.
1) Time spent by the linker (ld.so) before main() is called.
2) Initialisation of the X server connection and Qt toolkit.
3) Overhead by the KDE framework
4) Overhead by the application
Since the goal is to bring the startup-performance within 0.3 secs, each
contributor may spent on average 75ms.
I mention 2), 3) and 4) to make clear that the startup-performance is not tied
to a single element. However, each of these contributors places a limit on
the best achievable performance. I will continue to refer to 2), 3) and 4)
wrt performance for reference, but apart from that they are beyond the scope
of this paper.
As an example I have split up the startup times of the 'kedit' application
into 1), 2), 3) and 4), times are measured on a Pentium III running at 500Mhz.
All data is assumed to be already in memory so disk access should not play a
role.
Table1:
Activity Time Spent
Linking 0.65 sec
Qt app. constructor 0.13 sec
KDE app. constructor 0.11 sec
KEdit specific init 0.48 sec
---------------------------------------------
Total 1.37 sec
This illustrates that run-time link performance is the major bottleneck when
it comes to providing a "fast" desktop environment.
2. Run-time linking investigated.
=================================
The task of the runtime linker is to link an application to the shared libraries
it needs. There are several steps involved in this process. These steps involve:
1) Finding the shared libraries that are needed
2) Loading the shared libraries into the address space of the process.
3) Relocating addresses in the library to reflect the location in the address
space the library was loaded to.
4) Resolving undefined symbols in a library and/or the executable by searching
for these symbols in the other libraries.
All these steps, with exception of step 3, are optimized. It is step 3 that is
causing the problems:
1) Finding shared libraries is optimized by means of the /etc/ld.so.cache. The
ldconfig utility builds an index of all libraries found in the default library
locations and stores this index information in /etc/ld.so.cache. This cache
allows the linker to lookup libraries faster than if it had to search the file
system itself when looking for a certain library. If a library is not found in
the cache, the linker has to search the filesystem anyway.
2) Loading of shared libraries is cached by the Linux kernel. Only the first
application that needs a certain library needs to actually load the library
from disk. Subsequent processes that need the library will make use of the same
copy that already resides in memory.
This is further optimized by the fact that the Linux kernel only loads parts of
the library (on a page by page basis) when these parts are actually used.
4) Not all symbols are resolved at startup. Only when a symbol is used it is
being resolved. This is called lazy binding. By specifying "LD_BIND_NOW=t"
before starting an application, we can instruct the linker not to use lazy
binding and to resolve all symbols at startup. The following table shows
the results of lazy binding for the startup time of KEdit.
Table 2:
Lazy Binding Time needed for linking
On 0.65 sec
Off 1.17 sec
Symbol lookup is further optimized by the use of hash tables which makes the
lookup of symbols very efficient.
Lets now have a closer look at what happens in step 3)
Every library that is needed by an application gets loaded to an address that
is unique within that process. This address may vary each time the library is
loaded. Code that references addresses in the library must be adjusted for the
address the library is loaded to, this is called relocation. As mentioned before,
libraries are shared between different applications and processes. However,
the relocation performed can be different from process to process, as such,
those parts of the library that need to be relocated are not shared.
Let's now have a look at some numbers. When we compile and link the following
very simple application:
main(int argc, char *argv[]) { return 0; }
we will see that the startup time is determined by the number of libraries
this code is linked against. More accurately formulated, the startup time is
largely determined by the number of relocations that have to be performed.
The number of relocations can be counted by setting "LD_DEBUG=statistics".
The number of relocations and the start up time is measured independently
in case measuring the number of relocations slows down the relocation process.
LD_DEBUG=staticstics only counts the number of relocations that require a symbol
lookup.
In the following table, the startup time is listed as a function of the
libraries linked. Since the libraries depend on each other, each line also
implies the libraries listed above it. E.g. all data is cummulative.
Table 3:
Lazy Binding Bind all on startup
Libraries Relocations Time Relocations Time
C++ 945 0.01 1754 0.01
Qt *) 22176 0.12 32892 0.20
DCOP 22407 0.14 33669 0.24
kdecore **) 25095 0.20 39911 0.37
kdeui 42157 0.34 61586 0.60
kio ***) 43739 0.44 64978 0.78
kfile ****) 48915 0.60 73848 1.10
kspell 49366 0.66 74707 1.22
*) implies Xext, X11, SM, ICE, Xft, png, z, jpeg, Xrender
**) implies kdefakes, dl
***) implies kdesu, fam
****) implies ksycoca
Not only does the relocation take CPU time, it also uses up memory.
Table 4:
Lazy Binding Bind all on startup
Libraries Dirty Pages *) Dirty Pages
C++ 28 28
Qt 135 135
DCOP 137 137
kdecore 162 162
kdeui 189 189
kio 197 197
kfile 211 211
kspell 213 213
*) The last field of /proc//statm. (Linux 2.2.18)
Memory usage seems to be mostly caused by the .data sections of the libraries
which contain the vtables, and to a lesser extend by the .got section.
The following table shows the memory usage split by section. The table lists the 4
biggest libraries. Listed as "kedit" is the sum for all libraries (as well as the kedit
executable itself)
Table 4a:
.got .data .bss
libqt 44Kb 131Kb 19Kb
libkdecore 15Kb 17Kb 7Kb
libkdeui 24Kb 76Kb 4Kb
libXft 1Kb 5Kb 72Kb
kedit 129Kb 308Kb 160Kb
The next table shows the number of relocations per relocation type.
Relocations in the .got section are of type R_386_JUMP_SLOT and R_386_GLOB_DAT.
Relocations in the .data section are of type R_386_32 and R_386_RELATIVE.
Relocations of type R_386_32, R_386_JUMP_SLOT, R_386_GLOB require a symbol
lookup.
Relocations of type R_386_JUMP_SLOT are delayed until needed, unless
"LD_BIND_NOW" is specified.
Table 4b:
R_386_REL R_386_32 R_386_JUMP_SLOT R_386_GLOB_DAT
libqt 5124 17090 8515 2688
libkdecore 813 1719 3331 499
libkdeui 684 15547 4687 1529
libXft 2074 46 189 34
kedit 21021 43311 25866 7160
Since each relocation modifies 4 bytes of memory, so we can tranlate the above number
to Kb of memory affected:
Table 4c:
R_386_REL R_386_32 R_386_JUMP_SLOT R_386_GLOB_DAT
libqt 20Kb 67Kb 33Kb 10Kb
libkdecore 3Kb 7Kb 13Kb 2Kb
libkdeui 3Kb 61Kb 18Kb 6Kb
libXft 8Kb 0Kb 1Kb 0Kb
kedit 82Kb 169Kb 101Kb 28Kb
This shows that on average 100% of the .got section is affected by R_386_JUMP_SLOT
and R_386_GLOB_DAT relocations and 81% of the .data section is affected by R_386_REL
and R_386_32 relocations.
It is interesting to note that multiple R_386_32 entries can point to the same
symbol:
The following table lists the number of total R_386_32 entries per library as
well as the number of unique symbols referenced.
Table 4d:
R_386_32 Unique Symbols
libqt 17090 4377
libkdecore 1719 806
libkdeui 15547 2518
libXft 46 30
Caching symbol lookups related to R_386_32 relocations might give considerable savings.
Is this a KDE specific problem?
===============================
That depends on how you look at it. The problem of long startup times is caused
by the linker needing to do many relocations. In the case of KDE, these
relocations are for a great deal caused by vtable entries. KDE and Qt make
liberal use of virtual functions and inheritance. In general every class that
inherits from a base class with virtual functions will need to provide a vtable
that covers at least the virtual functions of this base class. It seems that
each vtable entry causes a relocation, and worse, a relocation that can not be
done lazy.
An example:
A class 'base' that defines 10 virtual functions will define a vtable for these
10 functions. All these functions need to be relocated at startup resulting in
10 relocations.
When I now define a class "derive" that inherits "base" and that overrides a
single virtual function, I will get a second vtable. I now need 20 relocations.
Qt is based on two fundamental classes, QObject and QWidget. QObject defines
about 8 virtual functions. QWidget about another 80.
As a test the following (dummy) class was added to a KDE library, the class
overrides an existing virtual function. The class was not used in any way.
By adding this class the number of relocations on startup increased with
110.
class TestClass : public QWidget
{
public:
TestClass() : QWidget() { }
virtual void initMetaObject() { QWidget::initMetaObjet(); }
};
Now it becomes clear why linking kdeui, a library that mostly defines widgets
who all inherit from QWidget, introduces 17000 additional relocations.
So to come back to the question, is this issue specific for KDE? Maybe.
As for a comparison. The GNOME 'gedit' application requires 2043 relocations
with lazy binding versus 9755 relocations with complete binding. It seems
that this application, written in C, takes more advantage of lazy binding
than applications in the KDE framework.
The following code was placed into a library as a test case:
#include <qwidget.h>
template<int T> class testclass : public QWidget
{
public:
virtual void setSizeIncrement(int w, int h) { QWidget::setSizeIncrement(w+T, h+T); }
};
template class testclass<1>;
...
template class testclass;
Note that these classes are not being used in any way. They only get defined.
In the table below the runtime startup performance versus the number of
classes is shown:
Table 5:
Number of Lazy Binding Delta Delta
Classes Relocations Time Relocations Time
1 23128 0.19 0 0.00
2 23237 0.19 109 0.00
3 23346 0.20 218 0.01
5 23564 0.20 436 0.01
10 24109 0.20 981 0.01
20 25199 0.21 2071 0.02
30 26289 0.22 3161 0.03
50 28469 0.23 5341 0.04
100 33919 0.28 10791 0.09
200 44819 0.36 21691 0.17
Each extra class introduces an extra 109 relocations and such a relocation
takes on average 8e-6 sec (CPU dependent).
4. A dirty hack: kdeinit
========================
Within KDE we have been looking for a solution to this problem. We found a
workable solution ("hack") which addresses the problem but think that a more
generic, fundamental and clean solution is in place.
The kdeinit solution is based on the notion that instead of launching
applications from scratch, we start a process that links against all important
KDE libraries. We then keep this process around in this "preloaded" state and
when we need to start an application, we let this process fork() and start the
application by dlopen'ing the application.
Their are 3 problems with this approach:
1) It is specific for KDE and KDE libraries
2) The application needs to be build as an ELF shared object instead of as a
ELF executable.
3) All your processes are called 'kdeinit'.
The two main advantages are worth this trouble though:
1) Application startup performance is improved with 0.65 sec on average.
(On 500Mhz PIII, this number is highly CPU bound)
2) Memory usage is reduced with about 800kb per process.
5. Suggestions
==============
There are two routes to improvement.
1) Improving efficiency of C++ vtable linking
One solution could be to make run-time
linking of vtables more efficient. If the linking/relocation of vtables could
be postponed till the first object of that class gets constructed, I expect that
the number of relocations during startup will drop dramatically if lazy binding
is enabled. KDE applications show a ratio of about 2:3 between
lazy and non lazy binding. The gedit example had a ratio of 1:5. If lazy binding
of KDE applications can be improved to a ratio of 1:5 the number of relocations
during startup would drop from 49366 to about 15000, which would result in the
link time dropping from 0.65 sec to 0.20 secs if we assume a linear relation.
2) pre-relocation/linking of libraries.
Another solution would be to add support for pre-relocating/linking libraries
in the linker. This solutions is IMO a more correct approach since it solves
the problem in a more fundamental way. The fundamental problem is that we are
doing a large number of relocations, over and over again (each time a KDE
application is started) basically we have a problem and solve that problem
over and over again. If we would solve the problem once and then reuse the
result we can save a lot CPU cycles instead of postponing the use of those
CPU cycles as we would do with solution 1.
There are a few decisions one can make when pre-relocating libraries.
Who will pre-relocate/link and when? Are the results stored on disk or in
memory? Are the results shared between different users?
When linking a library (and to a smaller degree when relocating) the result
is dependent on the other libraries. That means that the validity of a
pre-relocated/linked library depends on the other libraries that it depends on.
With kdeinit this problem is solved in an easy but crude way. When kdeinit
starts the libraries that are to be used are fixated, changes made to a library,
like upgrades, will not take effect until kdeinit is restarted. This way
the pre-relocated/lnked set of libraries will always remain in a consistent
state.
Although I consider this a crude way, it should be noted that most of the time,
especially if the owner of the system is not a KDE developer him or herself,
libraries do not change. Assuming that someone updates his system once a month,
that means that 29 out of 30 days his libraries remain the same.
6. Interesting papers
=====================
Dynamic Linking and Loading
http://iecc.com/linker/linker10.html(...)
Cross-Address Space Dynamic Linking
http://www.sun.com/research/techrep/1992/smli_tr-92-2.pdf(...)
High Performance Dynamic Linking Through Caching
http://www.usenix.org/publications/library/proceedings/cinci93/full(...)
Neutrino (R) System Architecture Guide -
Dynamic Linking in Neutrino
http://www.qnx.com/literature/nto_sysarch/dll.html(...)
Linker and Libraries Guide
http://docsun.cso.uiuc.edu:80/cgi-bin/nph-dweb/ab2/coll.45.5/LLM/@A(...))#CHAPTER6-35405?
M. Franz. Dynamic linking of software components.
IEEE Computer, vol 30, no 3, pp 74-81, March 1997.
SGI's IRIX "rebases" libraries which eleviates the need for actual
relocations, as descried by Shankar Unni in the following mail:
http://www.suse.de/~bastian/Export/linking_sgi.msg(...)
7. Change History
=================
Version 1.0:
Initial version
Version 1.1:
Added Change History
Added Table numbering
Added Table 5
Version 1.2:
Added Table 4a, 4b and 4c.
Added note that LD_DEBUG=staticstics only counts the number of relocations that
require a symbol lookup.
Added suggestion to cache symbol lookups related to R_386_32 relocations (Table 4d)
Version 1.3:
Added note that this paper describes gcc 2.95.
Added reference to SGI's IRIX.
[^] # Re: Openoffice.org RC3
Posté par Benjamin . Évalué à 4.
- D'abord le "je vais me faire modérer vers le bas mais...." (à deux reprises, félicitations!). Je comprends pas que cette technique fonctionne encore...
- Puis le fait de recopier un mail au lieu de le linker (mail qui avait déjà été linké maintes fois à l'époque où on avait "découvert" l'objprelink pour KDE)...
2 points /. !
Allez, comme tu n'as pas trop du lire ce que tu as recopié, je te préviens que "This paper is based on gcc 2.95, many of the issues described here have been fixed in gcc 3.1", donc comme critique de GCC, bof...
[^] # Re: Openoffice.org RC3
Posté par aegir_lf . Évalué à 1.
2) donc comme critique de GCC, bof... , merci d'illustrer par l'exemple ce que je disais : toute critique de GCC est "intégristement incorrecte".
Malgré les amélioration de GCC, plus de 90% du temps de démarrage d'une appli c++ vient des relocations, et le prelinkage permet de diviser par 2 ce nombre de relocations.
Pensais-tu que les développeurs de OO étaient stupides au point d'utiliser un prelink inutile ?
[^] # Re: Openoffice.org RC3
Posté par Benjamin . Évalué à 1.
Remarquer qu'un argument est obsolète, c'est intégriste... eh beh...
Et pourquoi prétends tu que je dis du mal de prelink ?
Allez hop: ceux qui exprimeront une opinion contraire à ce poste sont intégristes.
[^] # Re: Openoffice.org RC3
Posté par peau chat . Évalué à 2.
Ensuite, une appli C++ sous linux compilée avec GCC rame au démarrage, alors que ce n'est pas le cas sur les autres plateformes avec d'autres compilateurs.
J'ai toujours écrit que les choses s'amélioraient (depuis que WB a fait l'analyse initiale), mais nous sommes encore très loin du compte. De plus, GCC a ce problème en C++ mais pas en C.
Donc, oui, je critique GCC, et cette critique est toujours d'actualité.
Les choses se sont améliorées, et vont encore s'améliorer, je le sais, et je l'ai toujours dit.
Mon principal message est d'expliquer à ceux qui disent :
- OO c'est nul parce que ça rame au démarrage.
- KDE c'est nul parce que les applis mettent du temps à démarrer.
- C++ c'est nul parce que les applis rament.
Et bien en fait ces gens là ce trompent. Le problème vient du compilateur. Avec d'autres compilateurs, la donne change complètement. Le compilateur s'améliore, et en attendant qu'il se soit suffisamment amélioré, on a des moyens de substitution telles que les bidouilles du prelink, mais aujourd'hui cela reste quand même un problème.
Aujourd'hui, GCC est un mauvais compilateur C++.
C'est pas grave, on fait avec, et ça va changer progressivement.
[^] # Re: Openoffice.org RC3
Posté par Benjamin . Évalué à 0.
Et ? Le fait de ne pas dire que c'est un mauvais compilo tout court, ca fait de moi un intégriste ? Perso, si tu me trouves un meilleur compilo, je prends.. J'ai besoin d'un compilateur tournant sous Linux et BSD, permettant de faire tourner mes programmes C et C++ sur Linux et BSD x86, Linux PPC, et Linux Arm (Zaurus), tourner et cibler MSWin et MacOSX serait un petit plus...
Gcc est mauvais en C++... super, on le savait depuis l'affaire objprelink de kde... ca valait le coup d'insulter par deux fois les lecteurs... et de traiter d'intégriste ceux qui remarquent les posts vieux de deux ans..
[^] # Re: Openoffice.org RC3
Posté par peau chat . Évalué à 2.
[^] # Re: Openoffice.org RC3
Posté par un_brice (site web personnel) . Évalué à 2.
(Et merci pour les infos au fait, ça m'eviteras de raconter/croire des conneries plus longtemps)
Par contre, j'ai lu nulle part que prelink réduisait la redondance des v-tables ou diminuait la taille en mèmoire des binaires (ce qui est sûr c'est qu'il augmente la taille occupée sur le disque).
D'ailleurs, et si j'ai bien compris, réduire ces v-tables ne pourrais se faire qu'à la compilation parce que je vois pas comment savoir qui hérite de quoi à partir du binaire.
En plus, dans le cas où l'emplacement réservé à la librairie n'était pas disponible, ld fait son boulot normalement. Est-ce que ça suppose que les sections redondantes du binaire restent intactes ?
[^] # Re: Openoffice.org RC3
Posté par peau chat . Évalué à 3.
Ainsi au démarrage, l'adresse n'est calculée (et stockée) qu'une seule fois, au lieu de n fois.
Mais tout le monde est tout à fait d'accord : on peut largement améliorer les choses en intervenant directement sur le compilateur et l'éditeur de lien. Desz choses ont déjà été faites en ce sens, mais il reste encore bcp à faire.
# Re: Openoffice.org RC3
Posté par RLDF (site web personnel) . Évalué à -2.
la dernière version FR est la 1.0.3
[^] # Re: Openoffice.org RC3
Posté par herve . Évalué à 2.
j'ai la RC 2 de la 1.1 et elle est en français. Dispo sur le mirroirs francophones.
Il est bon de se renseigner avant d'être aussi catégorique.
# Re: Openoffice.org 1.1 RC3
Posté par zgnouf . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.