Au menu, des explications sur les raisons de certaines lenteurs de Gtk, et sur les multiples façons d'améliorer le tout.
En seulement deux jours de travail, l'auteur (aidé par Billy Biggs, Owen Taylor, Carl Worth et Keith Packard) a déjà réussi à gagner 24% de vitesse sur Pango.
Je vous laisse lire le reste et si certains d'entre vous sont des programmeurs/étudiants/professionnels/passionnés chevronnés disposant d'un peu de temps, n'hésitez pas à participer à cet effort d'optimisation et de profiling, car tout le bureau Gnome et toutes les applications GTK vont en bénéficier d'un coup ! L'auteur conseille notamment d'utiliser sysprof plutôt que gprof. C'est un profiler sous GPL avec une interface graphique qui fonctionne même avec les bibliothèques partagées, et qui ne nécessite ni de recompiler ni de redémarrer les applications.
L'auteur (se) donne également certains buts, comme de lancer le sélecteur de fichiers de Gtk et une fenêtre de Nautilus en moins de 0.1s, et également d'améliorer Pango et le widget d'arborescence de Gtk (GtkTreeView).
Entre autres, il remarque que :
- Les GLists, dont les performances s'écroulent avec le nombre d'éléments, sont trop utilisées et devraient être souvent remplacées par des tableaux (problème des algorithmes en O(n²)).
- Pango n'est pas lent à afficher le texte, mais à le mesurer, bien qu'il soit déjà correctement écrit et optimisé.
Aller plus loin
- Le diaporama (34 clics)
- Les travaux de Federico (17 clics)
- Gnome Summit 2005 (7 clics)
- Le profiler utilisé (6 clics)
# Effectivement
Posté par Guillaume Knispel . Évalué à 0.
Ça se lance en plus de 0.1s ? Effectivement ya du boulot à faire :)
[^] # Re: Effectivement
Posté par Nap . Évalué à 5.
[^] # Re: Effectivement
Posté par Batmat . Évalué à 2.
Par contre, gnome, c'est une horreur : il me faut bien 10 secondes pour avoir la main...
Ensuite, je ne sais pas non plus pourquoi, mais il me faut environ 1 minute je dirais pour que les applications qui doivent se lancer (liferea, gaim) se lancent et affichent leurs icônes dans la zone de notification :-/.
[^] # Re: Effectivement
Posté par Nap . Évalué à 4.
[^] # Re: Effectivement
Posté par Puppet_Master . Évalué à -8.
[^] # Re: Effectivement
Posté par klessou . Évalué à 4.
Ce qui m'embête depuis que j'ai la 2.10 et qui est peut être configurable, c'est la latence lorsqu'on essai d'aller sur le menu (la première fois où on clique dessus) ... Il doit surement rechercher de nouvelles appliquations à mettre dans le menu ou quelque chose dans le genre?!
[^] # Re: Effectivement
Posté par Prosper . Évalué à 7.
[^] # Re: Effectivement
Posté par gpe . Évalué à 3.
[^] # Re: Effectivement
Posté par matlj . Évalué à 5.
[^] # Re: Effectivement
Posté par liberforce (site web personnel) . Évalué à 2.
[^] # Re: Effectivement
Posté par salvaire . Évalué à 3.
[^] # Re: Effectivement
Posté par Anonyme . Évalué à 5.
Mais à vrai dire, les selecteurs de fichiers ne devraient même pas être au courant qu'ils sont sur AFS, et gérer les temps de latence comme si c'était un disque dur très lent.
Pour le reste, 1 seconde ça veut dire quoi ? Pas grand chose, je le suppose, tant qu'on ne définit pas une machine précise (processeur, carte mère, disque dur).
[^] # Re: Effectivement
Posté par salvaire . Évalué à 7.
Xmms par exemple ne devrait pas scanner /afs, ce qui est suicidaire. C'est une erreure de design. Scanner un système de fichier sur un disque local est rapide, mais pas en réseau. Linux n'est pas limité au desktop!
[^] # Re: Effectivement
Posté par Anonyme . Évalué à 5.
NFS lui ne teinte pas le noyau pour des problèmes de licence. J'ai tendance à penser que bosser sur NFS pour remplacer AFS ne serait pas une mauvaise.
« Xmms par exemple ne devrait pas scanner /afs, ce qui est suicidaire. C'est une erreure de design. Scanner un système de fichier sur un disque local est rapide, mais pas en réseau. »
Je ne connais pas vraiment ce domaine, mais je suppose que chercher dans fstab ou mtab si un dossier est sur un système de fichier en réseau risque assez vite d'être inbitable.
Je présume qu'il doit y avoir des timeout... mais je ne vois pas pourquoi un explorateur de fichiers graphiques devrait se comporter autrement que LS.
Et puisqu'on parle d'erreurs de conception, mettre plus de 100 dossier dans /afs, c'est plutot ça qui est suicidaire.
[^] # Re: Effectivement
Posté par Mathieu Pillard (site web personnel) . Évalué à 10.
[^] # Re: Effectivement
Posté par oops (site web personnel) . Évalué à 1.
Comme ?
Ne me parle pas de Juke / Amarok et autre bousin à gaz ou il faut 10 jours pour comprendre comment ca marche pour un non geek ....
[^] # Re: Effectivement
Posté par Erwan . Évalué à 5.
[^] # Re: Effectivement
Posté par Thomas Maurin (site web personnel) . Évalué à 2.
[^] # Re: Effectivement
Posté par matlj . Évalué à 4.
D'ailleurs, elle s'en sort beaucoup mieux que quand on utilisait xmms, parce qu'il n'y a plus d'accident de drag'n'drop, genre lâcher le bouton trop tôt, et m'appeler parce que sa musique n'est plus là..
[^] # Re: Effectivement
Posté par lezardbreton . Évalué à 5.
[^] # Re: Effectivement
Posté par Mathieu Pillard (site web personnel) . Évalué à 4.
[^] # Re: Effectivement
Posté par ccomb (site web personnel) . Évalué à 2.
[^] # Re: Effectivement
Posté par matlj . Évalué à 3.
[^] # Re: Effectivement
Posté par snt . Évalué à 8.
Sur mon pc poussif, xmms est la seule appli qui donne l'impression d'apparraite avant que j'ai fini mon double clic sur l'icone de mon fichier mp3.
Quand je pars pour ecouter pas mal de musique, j'utiliser amarok. Quand je veux juste ecouter rapidement un truc qui traine sur mon disque, xmms me plait bien.
[^] # Re: Effectivement
Posté par tgl . Évalué à 5.
> d'apparraite avant que j'ai fini mon double clic sur l'icone de mon
> fichier mp3.
C'est peut-être vrai sur un desktop utilisant déjà d'autres applis Gtk-1.2.x, mais sinon j'ai des doutes (charger tout un toolkit pour une seule appli, c'est toujours du gâchi, et ça se sent particulièrement sur une machine un peu poussive).
En fait, je pense que la façon la plus réactive d'ouvrir des mp3 par double-click, c'est de les balancer via mpc à un mpd qui tournerait déjà en arrière plan. Et en un peu moins rustique, un client mpd graphique (gmpc ou glurp pour les desktops Gtk-2, ou kmp pour les desktops Qt), ça doit pas mal se défendre aussi.
[^] # Re: Effectivement
Posté par Benjamin François (site web personnel) . Évalué à 2.
beep media player
Depends: libasound2, libatk1.0-0, libaudiofile0, libc6, libesd-alsa0, libglade2-0, libglib2.0-0, libgtk2.0-0, libid3-3.8.3c2, libogg0, libpango1.0-0, libstdc++6, libvorbis0a, libvorbisfile3, xlibs, libxml2, zlib1g
rhythmbox
Depends: libasound2, libatk1.0-0, libaudiofile0, libc6, libesd-alsa0, libglade2-0, libglib2.0-0, libgtk2.0-0, libid3-3.8.3c2, libogg0, libpango1.0-0, libstdc++6, libvorbis0a, libvorbisfile3, xlibs, libxml2, zlib1g
amarok
Depends: amarok-engine, kdelibs4c2, libc6, libgcc1, xlibs, libmysqlclient14, libpng12-0, libpq4, libqt3-mt, libstdc++6, libtag1c2, libtunepimp2c2, libgl1, zlib1g
totem
Depends: dbus-1, libart-2.0-2, libatk1.0-0, libaudiofile0, libbonobo2-0, libbonoboui2-0, libc6, libesd-alsa0, libfreetype6, libgconf2-4, libgcrypt11, libglade2-0, libglib2.0-0, libgnome-desktop-2, libgnome-keyring0, libgnome2-0, libgnomecanvas2-0, libgnomeui-0, libgnomevfs2-0, libgnutls11, libgpg-error0, libgtk2.0-0, libhal0, xlibs, libjpeg62, liblircclient0, libnautilus-burn1, liborbit2, libpango1.0-0, libpopt0, libstartup-notification0, libtasn1-2, libxine1, libxml2, libxrender1, zlib1g, gconf2
muine
Depends: libatk1.0-0, libbonobo2-0, libc6, libflac7, libgconf2-4, libgdbm3, libglib2.0-0, libgnomevfs2-0, libgstreamer-gconf0.8-0, libgstreamer0.8-0, libgtk2.0-0, libid3tag0, libogg0, liborbit2, libpango1.0-0, libvorbis0a, libvorbisfile3, libxml2, zlib1g, gstreamer0.8-gnomevfs, gconf2, mono-jit, libdbus-cil, libgconf2.0-cil, libglade2.0-cil, libglib2.0-cil, libgnome2.0-cil, libgtk2.0-cil, mono-classlib-1.0
banshee
Pas dans Debian.
juk
Depends: akode, kdelibs4c2, libarts1c2, libc6, libgcc1, libglib2.0-0, libgstreamer0.8-0, libmusicbrainz4c2, libqt3-mt, libstdc++6, libtag1c2, libtunepimp2c2, libxml2, zlib1g, libtunepimp-bin
Alors que Xmms...
Depends: libc6, libglib1.2, libgtk1.2, xlibs, libssl0.9.7, libxxf86vm1
Eh bin en ce qui me concerne, le choix est vite fait. Au passage, beep-media-player il fait quoi de plus que Xmms, à part ramer et couper la lecture lorsqu'on déplace une fenêtre ?
[^] # Re: Effectivement
Posté par gnujsa . Évalué à 8.
Ça ne change rien à ton propos: xmms est le plus légé de tous en terme de dépendance, et beep-media-player n'apporte fonctionnement rien de plus que xmms (et il possede beaucoup moins de plugin) (et son crossfading est completement bugué)
[^] # Re: Effectivement
Posté par dawar (site web personnel) . Évalué à 4.
[^] # Re: Effectivement
Posté par Grumbl . Évalué à 2.
Quand aux sélecteurs de fichiers, j'avoue ne pas connaître d'autre moyen de les faire fonctionner que scanner les répertoires. Si AFS ne sait pas faire, hé bien, qu'il soit une fois pour toute dit qu'une appli utilisant un sélecteur de fichiers ne devrait pas être utilisé en environnement AFS et qu'on en reste là (même s'il serait possible de faire interpréter la demande de scan de répertoire par la couche client AFS, mais bon..)
[^] # Re: Effectivement
Posté par salvaire . Évalué à 3.
Je faisais allusion à la fonction "Play directory"de xmms. Lancer un "find /afs -type d" est débile! La même chose doit être vrai sur n'importe quel système de fichiers en réseau. Les programmeurs devraient le savoir!
[^] # Re: Effectivement
Posté par Adrien BEAUCREUX . Évalué à 2.
Je ne parle pas de ma PME, mais le débat est autour de collections de musique, qui n'ont à mon avis rien à faire dans un environement professionel.
Quand bien même, si le réseau est si "--chargé--", n'as tu rien d'autre à faire que de le saturer encore plus avec de la musique ?
Sans parler de l'espace perdu, sur le disque comme sur les Backups?
Les besoins de l'entreprise et du particulier ne sont pas du tout les mêmes. Quel est donc le sens de ton argument?
Adrien
[^] # Re: Effectivement
Posté par TazForEver . Évalué à 0.
[^] # Re: Effectivement
Posté par N-Mi . Évalué à 5.
Y a-t-il une traduction officielle/majoritairement employée ?
[^] # Re: Effectivement
Posté par Guillaume Knispel . Évalué à 4.
[^] # Re: Effectivement
Posté par Guillaume Knispel . Évalué à 6.
Sur nos machines de fous actuelles attendre + de .1s juste pour voir le contenu d'un repertoire, c'est ... lent.
Et je parle même pas des attentes de plus de 1s décrites plus haut.
[^] # Re: Effectivement
Posté par pirouette_07 . Évalué à 4.
Pascal
# bla bla bla bla bla bla bla bla bla bla
Posté par philou (site web personnel) . Évalué à -10.
Où sont le infos utilisateurs pour améliorer les perfs ?
Ce donner des buts c'est bien, les réaliser c'est mieux. On sait tous que le nautilus devrais se lancer le plus rapidement possible; si à chaque idée, amélioration ou correction de bugs ; on "s'amuse" à faire une présentation préliminaire (nulle de plus), on n'est pas sortie.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par Dies Irae (site web personnel) . Évalué à 10.
La présentation ne donne pas seulement les objectifs, mais explique aussi comment ils ont réussi à optimiser pango et le sélecteur de fichier jusqu'à présent. Les articles sur le blog de Federico sont d'ailleurs très instructif à ce sujet.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par herodiade . Évalué à 5.
Ça me rappelle une question qui me vient souvent au sujet de la lenteur de Nautilus.
Bien qu'il ai moins de fonctionalités (p. ex. il n'utilise pas gnome-vfs), le navigateur de fichier (en gtk) rox-filer ( http://rox.sourceforge.net ) est incroyablement rapide, fulgurant, même sur des machines modestes. Une meilleur intégration dans gnome rendrai gnome utilisable sur les petites configs.
Pourtant rox-filer est snobbé par les distros (aucune ne le propose en alternative à Nautilus lors de l'install de gnome, il n'est pas dans les packages de Debian etc.) et bien sur par le projet gnome lui-même (on peut facilement choisir un mua alternatif à evolution, mais c'est plus difficile pour le gestionnaire de fichiers). Pourquoi ce logiciel, si performant, est ignoré de la sorte ?
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par Bapt (site web personnel) . Évalué à 5.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par herodiade . Évalué à 3.
Gnome permet de configurer de façon globale le mua, le tableur, le traitement de texte, l'éditeur, le navigateur, le lecteur audio/vidéo ... par défault, et c'est intégré dans les principales distros. Mais ce n'est pas le cas pour l'explorateur de fichiers.
rox-filer peut être installé et utilisé totalement indépendament du bureau rox. (et surtout, on peut le compiler à la main, quoiqu'en dise la doc, et eviter leur monstrueux système d'installation par default ;).
rox ne place pas la compatibilité avec freedesktop.org au centre de leurs priorités, ça ne facilte surement pas les choses.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par Cyrille Mars . Évalué à 4.
Sinon je ne peux que le conseiller ROX-Filer, je m'en sert depuis longtemps, je fais chier mon entourage avec ça tout le temps. La rapidité est vraiment une de ses qualité, et l'ergonomie aussi, bref, j'arrete je suis reparti a faire du prosélitisme roxien.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par mickabouille . Évalué à 2.
Par contre, je prends toujours cher quand je lance
rox /usr/share
(ou /usr/share/bin, /usr/lib, /usr/share/doc, etc)
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par dab . Évalué à 0.
rox /usr/share
Je ne vois pas ce qu'il y a d'illogique.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par dinomasque . Évalué à 4.
BeOS le faisait il y a 20 ans !
[^] # probleme nautilus ?
Posté par Juke (site web personnel) . Évalué à 4.
Comme quoi ?
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par gnujsa . Évalué à 2.
Si si, il s'appelle rox-filer:
http://packages.debian.org/stable/x11/rox-filer
« Bien qu'il ai moins de fonctionalités (p. ex. il n'utilise pas gnome-vfs) »
Apparement c'est possible, mais ça s'active à la compilation:
$ rox --version
ROX-Filer 2.2.0
Copyright (C) 2005 Thomas Leonard.
[...]
Compilé avec GTK version 2.6.8
Tournant avec GTK version 2.6.10
-- fonctionnalités fixées à la compilation --
Support des fichiers longs... Oui
Bibliothèque GNOME-VFS... Non (nécessite au moins 2.8.0)
Support dnotify... Oui
Compatibilité binaire... Non (apsymbols.h non trouvé)
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par lezardbreton . Évalué à 2.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par mickabouille . Évalué à 1.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par kd . Évalué à 4.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par mickabouille . Évalué à 5.
(note, ils sont bien dans debian, mais rox est très modifié, et gnustep a vu le couperet passer pas loin il n'y a pas si longtemps).
Quand des gens proposent des améliorations pratiques, il arrivequ'on leur réponde : "Non, c'est pas compatible avec la LSB". Conclusion? la LSB n'a pas l'air compatible avec les améliorations.
Il y a sûrement des bons pricipes dans la LSB, mais il n'y a pas besoin de tout suivre aveuglément.
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par Adrien BEAUCREUX . Évalué à 4.
L'incompatibilité Standard/innovation est courrante. Par définition, un standard est un consensus. Le temps que l'innovation arrive à pointer son nez, elle n'est généralement plus innovante, mais 'best practice'.
Au pire, il reste /opt.
Adrien
[^] # Re: bla bla bla bla bla bla bla bla bla bla
Posté par dinomasque . Évalué à 4.
C'est en gros un super répertoire avec le(s) binaire(s) et toutes les ressources nécéssaires au programme. Ca évite aux fichiers d'un logiciel d'être éparpillés partout dans le système de fichier et simplifie l'installation/déinstallation/déplacement des applications : un simple drag&drop suffit !
Le problème c'est que ce n'est pas du tout une façon de faire conforme à la LSB (ce dont à priori se foutent les gens de GNUstep qui vise à faire un Next-like et pas juste un système GNU).
BeOS le faisait il y a 20 ans !
# C'est nécessaire
Posté par reno . Évalué à 9.
[^] # Vae Victis
Posté par Anonyme . Évalué à -8.
[^] # Re: Vae Victis
Posté par Anonyme . Évalué à 10.
Et oui, pour ta gouverne BeOS est toujours up, et est véritablement utilisable (ie pas un simple OS de foire cf http://www.bebits.com/ ) et cet OS a toujours eu une bonne réputation notamment à cause de sa rapidité, et de sa vivacité en terme de "responsivness". Donc des fois faut savoir regarder et s'insiprer du meilleur et ne pas se borner qu'au monde GNU/Linux ou Win32
A bonne entendeur.
[^] # Re: Vae Victis
Posté par ZeroHeure . Évalué à 3.
Ah oui, il n'y a plus d'entreprise derriere... et puis il y a des clones libres en developpement, par des aficionados. Tiens c'est marrant, Linux aussi c'est developpe par des aficionados.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Vae Victis
Posté par reno . Évalué à 10.
Comme tu dis, il faut comparer des choses comparables: BeOS comme Linux ou Windows avait une interface graphique moderne, la protection de la mémoire, tournait sur plusieurs matériel, bref coté desktop il faisait grosso-modo la même chose mais il est/était beaucoup réactif, sur du matériel beaucoup plus faible.
Ce qui me parait être une bonne démonstration que le logiciel est plus important que le matériel pour les performances et donne une image bien peu flatteuse de l'état actuel de nos logiciels: un example bien que Linux ait un meilleur multi-threading que BeOS, il reste beaucoup plus lourd car peu d'application l'utilise vraiment: exemple, mozilla qui 'fait une pause' car il est en train de faire quelque-chose de complexe dans une tab alors qu'on essaye de visualiser autre-chose..
[^] # Re: Vae Victis
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
> de complexe dans une tab alors qu'on essaye de visualiser autre-chose..
T'as qu'a aller sur des pages moins trollifères quand tu surf sur linuxfr avec Mozilla ;-).
[^] # Re: C'est nécessaire
Posté par krumtrash . Évalué à 4.
J'avais utilisé à l'époque BeOS 5 PE Max Edition mais présentement je ne suis plus l'actualité BeOS alors entre zeta, aiku, open, blueyed, max etc... je suis tout perdu!
http://fr.wikipedia.org/wiki/BeOS
[^] # Désolé mais BeOS != libre
Posté par reno . Évalué à 2.
Je crois que le projet libre le plus avancé est Haiku, mais il est bien moins avancé que Zéta qui est fonctionnel lui (car issu du code originel de BeOS).
[^] # Re: Désolé mais BeOS != libre
Posté par matlj . Évalué à 1.
[^] # Re: Désolé mais BeOS != libre
Posté par tuiu pol . Évalué à 1.
[^] # Re: Désolé mais BeOS != libre
Posté par matlj . Évalué à 5.
Peu de temps avant le rachat, une partie des sources de Dano (la future version 6 de BeOS) s'est retrouvée illégalement sur le net.
Enfin, Yellowtab annonce Zeta, qui est basé sur les sources de Dano, justement. Malgré toutes les interrogations des internautes, ils n'ont jamais expliqué de quelle façon ils s'étaient procuré les sources, d'autant que Palm n'avait pas montré d'intérêt pour licencier ce code ((cf. initiative BeUnited) qu'ils comptaient à priori utiliser pour les futures versions de PalmOS.
[^] # Re: Désolé mais BeOS != libre
Posté par tuiu pol . Évalué à 1.
# Cela rassure
Posté par kd . Évalué à 10.
24% d'améliorations en vitesse, c'est énorme. Ça signifie que les programmeurs se soucient réellement peu de la vitesse de leur programme, ce qui est vraiment regrettable.
Le fait que ces 24% aient été obtenus en seulement 2 jours de travail montre à quel point, il peut sembler facile de faire attention à certains choix techniques quand on a en tête un certain soucis concernant la rapidité de ses programmes.
Personnellement, je n'ai jamais programmé de gros projets pour des vrais systèmes d'exploitation. Je programme plus régulièrement sur des petit systèmes avec des processeurs très peu puissants. La vitesse est donc très importante. L'optimisation de cette vitesse d'exécution est donc une partie importante du temps de développement. Et ce temps passé est légitime, car c'est à mon avis la vitesse et l'ergonomie d'utilisation d'un programme qui font l'essentiel d'un bon programme. Et il est regrettable que de nos jours, un programme qui tourne sur calculatrice est plus rapide qu'un programme sur un ordinateur ayant une puissance de calcul plus de 1000 fois plus élevée.
De même que pour la chasse aux bugs, il faudrait donner des prix pour ceux qui obtiennent le plus grand gain de vitesse dans un projet d'envergure tel que Gnome ou KDE.
[^] # Re: Cela rassure peu
Posté par Anonyme . Évalué à 5.
De même que pour la chasse aux bugs, il faudrait donner des prix pour ceux qui obtiennent le plus grand gain de vitesse dans un projet d'envergure tel que Gnome ou KDE. »
Comme tu l'expliques plus haut, ce qui n'est pas rassurant du tout d'ailleurs, ces gains de vitesse semblent plutôt témoigner de problèmes existants...
Ceci étant dit, moi je trouve KDE, depuis la serie 3.x, plutôt rapide.
[^] # Re: Cela rassure peu
Posté par kd . Évalué à 4.
Nous nous comprenons bien. Le titre que j'avais mis été censé être ironique. Je l'avais mis temporairement, avant de rédiger mon commentaire, et j'ai oublié de le changer.
Pour continuer, il faut dire qu'il est vraiment dommage que des projets tels que Gnome, KDE, OpenOffice soient lents ; d'autant plus lents que le matériel est ancien.
Comme je le disais, un des aspects qui me semble le plus important pour juger d'un programme, c'est la vitesse (et plus généralement l'ergonomie d'usage). C'est vraiment un facteur important. Il n'y a rien de plus énervant que de voir un programme se traîner lamentablement pour faire des choses parfois si simples de conception !
J'espère que le travail de l'auteur du diaporama servira d'exemple et qu'une nouvelle mentalité s'instaurera chez les développeurs.
[^] # Re: Cela rassure
Posté par bigben99 . Évalué à 9.
Le fait que ces 24% aient été obtenus en seulement 2 jours de travail montre à quel point, il peut sembler facile de faire attention à certains choix techniques quand on a en tête un certain soucis concernant la rapidité de ses programmes.
Moi ça m'étonne pas du tout. Généralement, le but d'un developpement est avant tout d'avoir une fonctionnalité. Une fois que celle-ci est présente, il n'y a pas de raison pour chercher à l'optimiser, sauf si les performances sont visiblement mauvaises ou que l'on sait pertinament qu'il y a une partie du code très sous-optimale.
Du coup, si on cherche à optimiser, on trouve facilement des gains importants au début.
[^] # Re: Cela rassure
Posté par gnumdk (site web personnel) . Évalué à 10.
C'est une bonne chose pour gnome mais il faudrait vraiment qu'il y'ait une petite équipe qui se concentre sur ca: l'optimisation.
Pour suivre la ml de kde-optimize depuis un moment, on y apprend tjs des truc interessant et même parfois surprenant(cf debat ++i vs i++)
http://mail.kde.org/pipermail/kde-optimize/
Dans le même genre, une optimisation pour fontconfig qui fait ramer les applis au démarrage(surtout avec plein de fonts installées):
http://www.kdedevelopers.org/node/1495
[^] # Re: Cela rassure
Posté par riri le breton (site web personnel) . Évalué à 2.
J'ai du mal à admettre que des développeurs chevronnés comme ceux bossant sur de gros projets comme KDE aient encore ce doute oO.
[^] # Re: Cela rassure
Posté par Guillaume Knispel . Évalué à 7.
En C++ très certainement quand on travaille sur des opérateurs surchargés sur des types non atomiques. En C, étant donné que l'on est forcement sur un type primitif, je ne vois pas l'interet (notamment une instruction i++; sera équivalente à une instruction ++i;, et expr(i++); => expr(i); i++; tandis que expr(++i); => i++; expr(i); ce qui revient au même en terme de vitesse).
[^] # Re: Cela rassure
Posté par djano . Évalué à 2.
La feinte est la suivante:
Dans le cas de l'instruction i++; ,
i++ incremente la variable i, mais renvoie la valeur de i avant l'incrementation. Il faut donc la stocker quelque part ailleurs.
++i incremente la variable i, et renvoie la valeur de i apres l'incrementation. Donc il n'y a pas de valeur a garder!
C'est un probleme de micro optimisations, mais on utilise tellement l'instruction suivante: i++; , que cela vaut le coup d'utiliser ++i; a la place, et ca ne mange pas de pain.
(Remarquez que l'on utilise aussi dans le for)
[^] # Re: Cela rassure
Posté par tgl . Évalué à 5.
[^] # Re: Cela rassure
Posté par Sebastien . Évalué à 5.
Mais bon, puisqu'on peut le faire, pourquoi le laisser faire par le compilo ?
Pour moi, ce genre de trucs (i++ -> ++i) ca fait partie des "good practices".
Comme, par exemple, tout le temps mettre la partie constante à gauche d'un == :
if ( 42 == universeMeaning ) {}
Ca ne mange pas de pain et ça sauve un temps précieux (en debugging).
D'ailleurs je proposerais bien de renommer le C++ en ++C ;)
[^] # Re: Cela rassure
Posté par Xavier Teyssier (site web personnel) . Évalué à 4.
[^] # Re: Cela rassure
Posté par dinomasque . Évalué à 0.
BeOS le faisait il y a 20 ans !
[^] # Re: Cela rassure
Posté par Sebastien . Évalué à 8.
[^] # Re: Cela rassure
Posté par bigben99 . Évalué à 4.
- avec "if (42 = universeMeaning)" tu as une erreur à la compilation (impossible d'affecter une valeur à 42),
- alors que dans l'autre sens "if (universeMeaning = 42)", tu n'as pas d'erreur de compilation mais le comportement n'est pas celui que tu voulais: 42 est affecté a la variable universeMeaning, et le if teste si universeMeaning est vrai (i.e. different de 0)
[^] # Re: Cela rassure
Posté par kd . Évalué à 2.
[^] # Re: Cela rassure
Posté par dinomasque . Évalué à 2.
BeOS le faisait il y a 20 ans !
[^] # Re: Cela rassure
Posté par durandal . Évalué à 2.
[^] # Re: Cela rassure
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Par contre, en fait, il n'y a pas vraiment de raison d'écrire i++, donc, pourquoi le faire ? Tu as rien a gagner, et un petit quelque chose à perdre.
L'habitude ? Bon, j'avoue, moi aussi, j'ai l'habitude d'écrire i++ et je continue à le faire, mais c'est pas pour autant que c'est une bonne habitude. Mais on est d'accord que ce n'est pas là que se trouvent l'essentiel des optimisations.
[^] # Re: Cela rassure
Posté par riri le breton (site web personnel) . Évalué à 1.
Sinon il y a une grosse différence entre i++ et ++i (il n'y a pas deux opérateurs pour rien), et c'est intéressant de se poser la question dès que l'on a un lien avec une autre variable ou une comparaison.
Par exemple :
while (padding++ < 0) {
*outstr++ = pad;
}
Dans ce cas, j'utiliserai l'incrémentation postfixe car j'ai une dépendance sur un test (et le 'padding' resert après dans un autre test). Sinon, sauf contre-indication, j'utilise l'infixe, car cela ne change rien à mon code, et je n'ai pas à me soucier de savoir si cela va être optimisé ou non.
[^] # Re: Cela rassure
Posté par Guillaume Knispel . Évalué à 2.
Reste que vu que ça ne coute rien de le faire, et que ca habitue au BIEN dans le cas où on coderait aussi en C++ avec des opérateurs surchargés, je n'aurais rien à redire à quelqu'un qui fait systématiquement ça en C (pas plus qu'à quelqu'un qui ne le fait pas). Par contre le premier qui s'amuse à modifier un programme pour remplacer tous les postfixes sur des types primitif par un préfixe, je lui demanderais probablement s'il n'a que ça à foutre.
[^] # Re: Cela rassure
Posté par cassidy . Évalué à 4.
http://mail.gnome.org/mailman/listinfo/performance-list
[^] # Re: Cela rassure
Posté par Philippe F (site web personnel) . Évalué à 4.
Cette histoire de glist en O(n2) est quand meme pathetique. C'est pas comme si on decouvrait un nouveau truc. On est en 2005, ca fait des annees qu'on connait des algorithmes et des heuristiques d'optimisations de liste. Optimiser une gestion de liste, c'est un exercice d'etudiant de 1e annee d'informatique. Se dire que l'un des meilleurs bureaux graphique de la planete en est encore la, ca fait peur.
Si tu regardes l'historique de glist, tu vois que ca n'a jamais pratiquement bouge. D'un cote, c'est bon signe, ca veut dire qu'elle a satsifait tous les besoins depuis des annees sans modification. Mais si tu regardes du cote de Qt, tu vois que au fil des ans, il y a eu pas mal de reflexion autour de la bonne facon d'optimiser une qlist.
Ca fait des annees que KDE se soucie de l'optimisation (la liste kde-optimize etant un symptome, creee en 2002), a cause de son image de bloatware. Quand je vois le niveau des mecs qui y poste d'ailleurs, je me sens tres tres humble.
Pour rappel, des trucs comme le prelinking ont ete inventes par des mecs de KDE, pour resoudre des problemes de performance du chargeur de lib de linux.
[^] # Re: Cela rassure
Posté par Sano . Évalué à 7.
Cela en sachant que l'ordinateur qui est en dessous est souvent des milliers de fois plus puissant que celui qui a servi à envoyer des gens sur la lune (et à les ramener vivants).
Personnellement, j'ai toujours considéré ça comme une aberration, mais ça n'a l'air de choquer personne dans mon entourage.
"Dis donc, ça fait bien 30s qu'il patine, là, ton 3GHz dual-core"
"Bah attends, ce document fait quand même 500 pages, hein"
*Sano*
[^] # Re: Cela rassure
Posté par philip . Évalué à 2.
c'est cool
j'aime les gnomes !
[^] # Re: Cela rassure
Posté par GnunuX (site web personnel) . Évalué à 4.
[^] # Re: Cela rassure
Posté par oliv . Évalué à 1.
[^] # Re: Cela rassure
Posté par olivn . Évalué à 0.
Mais il vaut mieux avoir un un terminal très rapide et se passer de quelques fonctionalités.
[^] # Re: Cela rassure
Posté par mickabouille . Évalué à 6.
[^] # Re: Cela rassure
Posté par oliv . Évalué à 2.
J'ai testé hier rxvt, aterm, xterm, konsole et gnome-terminal. rxvt est le plus rapide (2.76s pour le test), talonné par aterm (2.8s). Plus loin arrive Konsole (5.75s, avec fontes vectorielles ou bitmap, peu de différence). Ces 3 terminaux semblent tout à fait performants. Xterm se trouve au delà des 20s (21 et des poussières je crois, avec des fontes bitmap). Enfin, et queue de peloton, Gnome-terminal avec plus de 25s en fontes vectorielles, et un peu moins en fontes bitmap.
Donc, je dirais que rxvt est très bon. aterm, prenant moitié moins de mémoire (avec pseudo-transparence tintée sur ma bécane) va resté mon terminal de choix. Et Konsole est très impressionant !
[^] # Re: Cela rassure
Posté par tgl . Évalué à 3.
http://thread.gmane.org/gmane.linux.gentoo.devel/30624
(note : ça vient de gentoo-dev@, mais la problématique n'a rien de spécifique à cette distrib')
[^] # Re: Cela rassure
Posté par gpe . Évalué à 0.
[^] # Re: Cela rassure
Posté par gpe . Évalué à 1.
Bizarre, j'ai fais le test chez moi avec xterm et gnome-terminal (fonte par défaut, bitmap je suppose?).
Résultat: gnome-terminal est au moins 2 fois plus rapide que xterm...
[^] # Re: Cela rassure
Posté par tgl . Évalué à 2.
Perso, ce résultat de gnome-term 2x plus rapide que xterm, c'était avec :
- des terms de même taille (plein écran)
- sans barre de scroll
- police bitmap Lucida TypeWriter 9pt
- gnome-terminal-2.12.0 / GTK+-2.8.6 (et tout le bazar gnomesque dans ses dernières versions)
- xterm-204
[^] # Re: Cela rassure
Posté par gpe . Évalué à 1.
Pour les polices c'étai les polices standards.
[^] # Re: Cela rassure
Posté par tgl . Évalué à 4.
Suite au lien posté par GnunuX (merci), et au second billet sur le même blog [1], j'ai moi aussi comparé les vitesses de gnome-terminal et xterm. En gros, avec des terminaux en plein écran, et des polices de tailles similaires :
- gnome-terminal en TrueType est 4x plus lent que Xterm en bitmap ;
- gnome-terminal en bitmap est 2x plus rapide que Xterm en bitmap, et donc 8x plus rapide qu'en TrueType !
Le vainqueur haut la main de cette comparaison est donc bien gnome-terminal, et perso j'apprécie vraiment la nouvelle jeunesse que lui confèrent les polices bitmap, même si mes yeux regrettent un peu sa douceur baveuse d'antan.
Bon, ça c'est pour le point de vue utilisateur. Maintenant, du côté code, j'ai l'impression que la lenteur de gnome-terminal en TrueType n'est en fait pas encore bien comprise : McEs accuse plutôt XFT (ce qui semblait effectivement logique quand on lit les tests de son premier billet), mais quelqu'un lui à répondu que Konsole en TrueType, avec XFT aussi donc mais via Qt, ne souffrait pas de ces lenteur lui. Mystère donc...
[1] http://mces.blogspot.com/2005/10/behdads-pango-roadmap.html
[^] # Re: Cela rassure
Posté par tgl . Évalué à 2.
[^] # Re: Cela rassure
Posté par durandal . Évalué à 0.
[^] # Re: Cela rassure
Posté par tgl . Évalué à 6.
Ça date un peu, mais à une époque j'avais benché "emerge" (le machin qui compile les paquets sous Gentoo), en mode normal d'une part (avec les commandes de compil', le listing des fichiers installés, etc.) et dans un mode silencieux d'autre part, qui cachait tous ces dumps superflus. Bah dans un gnome-terminal, la différence était vraiment loin d'être négligeable :
https://bugs.gentoo.org/attachment.cgi?id=23318
[^] # Re: Cela rassure
Posté par cassidy . Évalué à 4.
[^] # Re: Cela rassure
Posté par Guillaume Knispel . Évalué à 5.
[^] # Re: Cela rassure
Posté par tgl . Évalué à 6.
[^] # Re: Cela rassure
Posté par durandal . Évalué à 1.
time for x in `seq 10000`; do echo {a,b,c,d,e}{A,B,C,D,E}; done
me donne avec Eterm :
real 0m1.661s
user 0m1.284s
sys 0m0.052s
avec rxvt :
real 0m1.382s
user 0m1.248s
sys 0m0.048s
avec gnome-terminal (réglages de police par défaut, donc truetype) :
real 0m5.330s
user 0m1.292s
sys 0m0.028s
C'est bizarre, les résultats sont irréguliers : j'ai eu entre 5 et 24s pour différents tests.
xterm :
real 0m20.240s
user 0m1.592s
sys 0m0.120s
Mes résultats ne sont vraiment pas terribles par rapport à d'autres tests avec ce terminal, je ne sais pas pourquoi (je n'ai pas de police truetype).
On sent bien dans certains terminaux des petits lags rien qu'à l'affichage d'un caractère. J'utilisais sans le savoir un des plus rapides donc finalement la vitesse a peut-être influé sur mon choix, Eterm est encore plus parfait que ce que je pensais. ;)
# sysprof
Posté par herodiade . Évalué à 6.
Les principes et fonctionalités sont les mêmes: il s'appui sur les fonctionalités de profiling du noyau Linux (ça ne marche pas sur d'autres plateformes), il ne nécéssite pas d'options spécifiques lors de la compilation des binaires à profiler, il ne grève presque pas les perfs, et il permet de profiler un environnement en prod de a à z sans en perturber le fonctionnement.
OProfile est moins joli que sysprof mais peut être utile pour les inconditionels de la console, pour ceux qui veulent profiler sur des machines sans x11 (par ex. des serveurs en prod), ou integrer un outil de profiling dans des shells scripts.
nb: dans tout les cas (sysprof ou oprofile) il faut compiler son noyau avec le support pour le profiling.
[^] # Re: sysprof
Posté par Sebastien . Évalué à 1.
Humm... C'est pas un peu aventureux de faire tourner oprofile sur un serveur en prod ?
Parce que je me suis laisse dire que si (le module d') oprofile partait en sucette, c'etait tout le kernel qui se vautrait.
On m'aurait menti ? (C'est une vraie question)
[^] # Re: sysprof
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: sysprof
Posté par Sebastien . Évalué à 3.
Mais on m'avait fait comprendre a mots couverts que la stabilite du module n'etait pas au rendez-vous et qu'il n'etait donc pas question de mettre celui-ci en production sur notre cluster.
Comme je suis un beotien en la matiere j'ai benoitement (naivement?) accepte cet argument d'autorite.
Le gros probleme (a ce que j'ai compris) c'est qu'il faut faire tourner oprofile avec les privileges de root. Je suppose que cela devait un peu gener notre GIT (gentil IT).
[^] # Re: sysprof
Posté par tgl . Évalué à 3.
http://thread.gmane.org/gmane.linux.kernel/333049
Ce qui en ressort en gros, c'est que :
- niveau kernel-space, le module sysprof est redondant par rapport à celui d'oprofile, et semble plutôt avoir été écrit parceque son auteur sous-estimait oprofile ou le connaissait mal.
- la redondance sur cette partie n'est somme toute pas bien grave vu qu'il s'agit de qlqs centaines de lignes de code au plus.
- par contre, beaucoup de gens voudraient pouvoir utiliser la GUI de sysprof avec leur module de profiling habituel (oprofile). C'est vraiment cet outil d'analyse qui semble faire l'intérêt de sysprof.
# Comment font-ils leurs tests ?
Posté par l'enfant de la lune . Évalué à -8.
Avec quoi tous les développeurs de gnome, kde, et toutes ces usines à gaz font-ils leur tests ? Avec des machines ultra performantes ? Non je ne pense pas, alors comment peut-on en arriver à essayer de rassembler la communauté pour optimiser les perfomances de Gnome ? Les concepteurs auraient dû y penser avant ! A mon sens on devrait tout simplement le jeter à la poubelle ...
[^] # Re: Comment font-ils leurs tests ?
Posté par vincent LECOQ (site web personnel) . Évalué à 3.
Certes c'est tout plein d'effets, mais ca met un max de temps a sortir ! :(
[^] # Re: Comment font-ils leurs tests ?
Posté par Damien Pobel (site web personnel) . Évalué à 5.
En tout cas, je vois les choses comme ça...
https://damien.pobel.fr
[^] # Re: Comment font-ils leurs tests ?
Posté par herodiade . Évalué à 8.
Bref, qu'ils parviennent à considérablement améliorer les choses ne signifie pas que l'archi était mauvaise. Et c'est typiquement un travail qu'il faut toujours faire dans l'après coup. « Premature optimisations is the root of all evil » comme chacun sait.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.