Développeur : Rendre GNOME rapide
Posté par ccomb (Jabber id, page perso, ). Modéré le 14 octobre 2005.
C'est le titre d'un diaporama présenté par Federico Mena-Quintero lors du GNOME Summit 2005 qui a eu lieu à Boston du 8 au 10 octobre dernier.
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 !
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 !
Le diaporama (2255 hits)
Les travaux de Federico (1028 hits)
Gnome Summit 2005 (339 hits)
Le profiler utilisé (749 hits)
> Lire la dépêche (116 commentaires, moyenne: 3,5).
Vous avez demandé le commentaire #636376.




Effectivement
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).
Ça se lance en plus de 0.1s ? Effectivement ya du boulot à faire :)
[^]Re: Effectivement
la fenêtre nautilus, c'est insupportable le temps que ça met (plus d'une seconde), même sur mon sempron 2.4 GHz avec 1Go de RAM, alors que le système vient de booter.
[^]Re: Effectivement
Marrant, chez moi, nautilus s'ouvre assez vite (portable Centrino 1.6Ghz, 1Go RAM, Ati radeon 128Mo), genre immédiatement à l'appui sur le bouton du clavier que j'ai configuré comme raccourci.
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
j'ai eu ça une fois avec beagled à cause d'un numéro de priorité trop faible dans la configuration du lancement des programmes. Augmente les numéros et mets au moins 60à chacun.
[+] [^]Re: Effectivement
voila une idée qu'elle est bonne !!!!
[^]Re: Effectivement
Je trouve que Nautilus est plutôt rapide après le premier démarage.
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?!
Logiciel Libre à Telecom Lille 1
[^]Re: Effectivement
Je pense plutot que c'est l affichage des icones du dit menu qui prends du temps , ensuite c'est mis en cache , ca va tout de suite plus vite.
[^]Re: Effectivement
J'ai également cette latence à la première utilisation du menu mais c'est Gnome 2.10 qui a introduit ça. En 2.8 il n'y avait pas de latence...
[^]Re: Effectivement
Ce problème est corrigé dans Gnome 2.12
[^]Re: Effectivement
C'est un des points qu'ils comptent bientôt optimiser aussi...
[^]Re: Effectivement
J'ai remarqué que les sélecteurs de fichiers ne font pas bon ménage avec AFS. Pour Xmms c'est fatal, pour gtk 1 min c'est long ...
[^]Re: Effectivement
AFS ? Qui utilise AFS hormis quelques institutions internationales (OpenAFS teinte le noyau) ?
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
AFS est indispensable quand les inconvéniants de NFS ne sont pas tolérable.
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
« AFS est indispensable quand les inconvéniants de NFS ne sont pas tolérable. »
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
Et utiliser xmms en 2005 c'est pas suicidaire, c'est juste dommage vu la quantité d'applis qui font la meme chose, ou le meme genre de choses, en mieux, plus joli et plus moderne :-)
[^]Re: Effectivement
>Et utiliser xmms en 2005 c'est pas suicidaire, c'est juste dommage vu >la quantité d'applis qui font la meme chose, ou le meme genre de >choses, en mieux, plus joli et plus moderne :-)
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
Muine! Prise en main d'un non-geek: 30 secondes.
[^]Re: Effectivement
Perso je préfère passer par Totem-2.12, au moins je n'ai pas à installer tout mono juste pour une appli.
[^]Re: Effectivement
Ma copine utilise amarok tous les jours et s'en sort très bien. Elle n'a pourtant *rien* d'une geekette.
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
Faut pas exagérer : Amarok et Juk sont utilisables par des débutants. Ils ont juste besoin de 5 minutes d'initiation (qu'est ce que c'est qu'une collection, une liste de lecture, et puis c'est à peu près tout).
[^]Re: Effectivement
beep media player, rhythmbox, amarok, totem, muine, banshee, juk, mpd + un bon client (il yen a :), etc.
[^]Re: Effectivement
Parmi ces lecteurs, lequels peuvent faire du crossfade entre les morceaux ?
[^]Re: Effectivement
BMP, amaroK, et mpd
[^]Re: Effectivement
Et utiliser xmms en 2005 c'est pas suicidaire, c'est juste dommage vu la quantité d'applis qui font la meme chose, ou le meme genre de choses, en mieux, plus joli et plus moderne :-)
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
> 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.
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
Voyons voir ce que ça donne les applis "jolie et moderne" qui lisent des mp3.
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
Ta façon de détailler les dépendances reflete mal la réalité. Par exemple, amarok, tout comme beep media player ou totem, depend aussi de libxml2, libasound2, et d'autres encore, mais c'est camouflé par cette grosse meta-dépendance de kdelibs4c2. Du coup, on a l'impression d'avoir a faire à un lecteur légé !
Ç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
Pareil, pour moi c'est xmms, j'ai commencé avec, il fait ce dont j'ai besoin et bien plus avec ses plugin, il est léger comme tout et surtout je supporte pas les lecteurs multimédia usine a gaz a la itune ou je pige rien au fonctionnement. Le GTK1 je m'en fous, c'est skinné je le vois jamais vu que c'est mon selecteur de fichier qui me permet de gerer ma musique et de la balancer a xmms.
[^]Re: Effectivement
Je pense que les sites contournant par l'une ou l'autre des méthodes connues applicables les défauts bien connus de NFS sont plus nombreux que ceux s'accomodant des défauts mal identifiés d'AFS.
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
Il me semble que les raisons invoqués pour l'utilisation d'AFS, sont la sécurité et la résistance à la charge. NFS est très bien pour une dizaine de clients. Mais avec 2000 clients et un réseau --chargé-- ont sature totalement le serveur et le réseau. Mais c'est très particulier. De plus, si NFS n'est pas utilisé c'est qu'il y a une raison! Alors ne me parler du cas de votre pme.
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
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
on ne dit pas "teinte" mais "contamine".
[^]Re: Effectivement
Ah, moi j'avais plutôt l'habitude de traduire ça par "souille" (me souviens plus d'ailleurs où j'avais entendu cette traduction).
Y a-t-il une traduction officielle/majoritairement employée ?
[^]Re: Effectivement
Pourrir est assez commun :)
[^]Re: Effectivement
Nan mais en fait il était sérieux mon commentaire (malgré le smiley). Bon ok j'accorde qu'il était inutile aussi :)
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
z'ont pas d'humour les moinsseurs ;-)
Pascal