Articles précédents : Développeur
- [82] Flash player 8 recherche son ingénieur linux
- [16] Le projet BBClone cherche un repreneur
- [3] Préparation de l'atelier Netfilter 2005
- [6] Nouvelles du noyau : Git et modèle de développement
- [47] FFmpeg et MPlayer : Appel au dons pour un nouveau serveur
- [56] Bilan du sommet 2005 des développeurs du noyau Linux
- [66] Le moteur de Gecko en version serveur ?
- [11] JSAN : un « CPAN » pour JavaScript
- [74] Sortie de Qt 4
- [120] Support d'Ajax dans Ruby on Rails
Liens connexes
- Le diaporama (2244 hits)
- Les travaux de Federico (1024 hits)
- Gnome Summit 2005 (335 hits)
- Le profiler utilisé (744 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Rendre GNOME rapide
Posté par ccomb (Jabber id, page perso, ). Modéré le 14 octobre 2005.
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 !
![[en]](../../../images/en.png)
Le diaporama (2244 hits)-
Les travaux de Federico (1024 hits)
-
Gnome Summit 2005 (335 hits)
-
Le profiler utilisé (744 hits)
> Lire la dépêche (116 commentaires, moyenne: 3,5).
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é.
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
Posté par Nap (page perso, ) le 14/10/2005 à 13:30. (lien). Évalué à 5.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
Posté par Batmat (page perso, ) le 14/10/2005 à 13:40. (lien). Évalué à 2.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
Posté par Nap (page perso, ) le 14/10/2005 à 15:51. (lien). Évalué à 4.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
Posté par Puppet_Master () le 14/10/2005 à 13:43. (lien). Évalué à -8.voila une idée qu'elle est bonne !!!!
-
[^]Re: Effectivement
Posté par klessou (Jabber id, ) le 14/10/2005 à 13:47. (lien). Évalué à 4.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?!-
[^]Re: Effectivement
Posté par PasChauve PasOunet () le 14/10/2005 à 14:51. (lien). Évalué à 7.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
Posté par liberforce (Jabber id, page perso, ) le 14/10/2005 à 16:55. (lien). Évalué à 2.C'est un des points qu'ils comptent bientôt optimiser aussi...
-
-
-
[^]Re: Effectivement
Posté par salvaire () le 14/10/2005 à 16:06. (lien). Évalué à 3.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
Posté par gnap gnap (page perso, ) le 14/10/2005 à 17:17. (lien). Évalué à 5.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
Posté par salvaire () le 14/10/2005 à 18:11. (lien). Évalué à 7.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
Posté par gnap gnap (page perso, ) le 14/10/2005 à 19:07. (lien). Évalué à 5.« 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
Posté par Mathieu Pillard (page perso, ) le 14/10/2005 à 23:28. (lien). Évalué à 10.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
Posté par oops (page perso, ) le 15/10/2005 à 08:46. (lien). Évalué à 1.>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
Posté par Erwan (page perso, ) le 15/10/2005 à 09:00. (lien). Évalué à 5.Muine! Prise en main d'un non-geek: 30 secondes.
-
[^]Re: Effectivement
-
-
[^]Re: Effectivement
Posté par matlj (Jabber id, ) le 15/10/2005 à 09:32. (lien). Évalué à 4.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
Posté par lezardbreton (Jabber id, page perso, ) le 15/10/2005 à 10:18. (lien). Évalué à 5.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
Posté par Mathieu Pillard (page perso, ) le 15/10/2005 à 10:57. (lien). Évalué à 4.beep media player, rhythmbox, amarok, totem, muine, banshee, juk, mpd + un bon client (il yen a :), etc.
-
-
[^]Re: Effectivement
Posté par snt () le 15/10/2005 à 09:55. (lien). Évalué à 8.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
Posté par tgl () le 15/10/2005 à 15:33. (lien). Évalué à 5.> 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
Posté par Benjamin François (page perso, ) le 16/10/2005 à 22:05. (lien). Évalué à 2.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
Posté par gnujsa () le 16/10/2005 à 23:05. (lien). Évalué à 8.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
Posté par dawar (page perso, ) le 17/10/2005 à 10:13. (lien). Évalué à 4.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
Posté par Grumbl (page perso, ) le 15/10/2005 à 13:36. (lien). Évalué à 2.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
Posté par salvaire () le 15/10/2005 à 18:40. (lien). Évalué à 3.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.
scanner
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 () le 17/10/2005 à 19:14. (lien). Évalué à 2.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 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 () le 15/10/2005 à 09:32. (lien). Évalué à 0.on ne dit pas "teinte" mais "contamine".
-
[^]Re: Effectivement
Posté par N-Mi () le 15/10/2005 à 11:11. (lien). Évalué à 5.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
Posté par Guillaume Knispel () le 16/10/2005 à 23:50. (lien). Évalué à 4.Pourrir est assez commun :)
-
-
-
-
-
[^]Re: Effectivement
Posté par Guillaume Knispel () le 14/10/2005 à 17:12. (lien). Évalué à 6.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
Posté par pirouette_07 (page perso, ) le 14/10/2005 à 17:14. (lien). Évalué à 4.z'ont pas d'humour les moinsseurs ;-)
Pascal
[+] bla bla bla bla bla bla bla bla bla bla
Il n'y a franchement rien dans cette news.
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 (page perso, ) le 14/10/2005 à 16:49. (lien). Évalué à 10.Il n'y a franchement rien dans ton commentaire: à tu pris le temps de lire les liens donnés?
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 () le 15/10/2005 à 11:21. (lien). Évalué à 5.On sait tous que le nautilus devrais se lancer le plus rapidement possible
Ç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 (page perso, ) le 15/10/2005 à 11:33. (lien). Évalué à 5.Rox-filler n'est jamais proposé en alternative à nautilus, peut être parce que ce n'est pas un programme gnome, c'est le navigateur de fichier du bureau ROX ( bureau à part entière)
-
[^]Re: bla bla bla bla bla bla bla bla bla bla
Posté par herodiade () le 15/10/2005 à 12:39. (lien). Évalué à 3.Oui oui, bien sûr, ROX n'est pas un programme gnome. Ce que je voulais dire, c'est que dans gnome, il est possible de remplacer (efficacement, simplement, globalement) evolution par sylpheed, epiphany par firefox, abiword par oofice, etc. bref, les applis natives par des applis tierces (eg. venant de KDE).
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 (page perso, ) le 16/10/2005 à 21:40. (lien). Évalué à 4.au niveau de la compatibilité avec freedesktop le projet ROX est plutot avancé a certain niveau, les themes d'icones par exemple utilisent les convention de nomage de freedesktop depuis longtemps (et gnome toujours pas) et c'est en general une de leurs préocupations (je suis abonné à la ML). A quoi tu pensais en particulier ?
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 Mickaël L () le 17/10/2005 à 10:32. (lien). Évalué à 2.Je l'ai choisi aussi pour ça (rapidité-légèreté) et aussi parce q'il y a eu des histoires pas très sympas dans le développement de nautilus.
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 () le 17/10/2005 à 20:59. (lien). Évalué à 0.Par contre, je prends toujours cher quand je lance
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 Aurélien Girard () le 18/10/2005 à 07:52. (lien). Évalué à 4.Sort de là Jean Roucas, on t'a reconnu !
-
-
[^]probleme nautilus ?
Posté par Juke (Jabber id, page perso, ) le 17/10/2005 à 23:46. (lien). Évalué à 4.> et aussi parce q'il y a eu des histoires pas très sympas dans le développement de nautilus.
Comme quoi ?
-
-
-
-
-
[^]Re: bla bla bla bla bla bla bla bla bla bla
Posté par gnujsa () le 15/10/2005 à 16:56. (lien). Évalué à 2.« il n'est pas dans les packages de Debian »
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 (Jabber id, page perso, ) le 15/10/2005 à 17:58. (lien). Évalué à 2.A une époque rox n'était pas dispo sous Debian, ça avait fait pas mal de trolls, je ne me rappelle plus pour quelles raisons ils n'en voulaient pas.
-
[^]Re: bla bla bla bla bla bla bla bla bla bla
Posté par Mickaël L () le 16/10/2005 à 17:43. (lien). Évalué à 1.À cause de la façon de disposer ses fichiers. Une des rares choses que je reproche à Debian est de vouloir suivre la LSB
-
[^]Re: bla bla bla bla bla bla bla bla bla bla
Posté par Khanh-Dang (page perso, ) le 16/10/2005 à 19:06. (lien). Évalué à 4.Quel mal y a-t-il à vouloir suivre la LSB, de manière générale ?
-
[^]Re: bla bla bla bla bla bla bla bla bla bla
Posté par Mickaël L () le 17/10/2005 à 10:37. (lien). Évalué à 5.Ça interdit à certains programme de disposer leurs fichiers suivant leur manière "naturelle" : Rox, Gnustep, peut être d'autres.
(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 () le 17/10/2005 à 19:23. (lien). Évalué à 4.Par contre, les devs ne peuvent pas rendre leur programme compatible avec la LSB ? Puisque c'est censé être standard, c'est peut-être un bon calcul pour le long terme de s'y conformer.
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 Aurélien Girard () le 18/10/2005 à 07:56. (lien). Évalué à 4.ROX et GNUstep utilisent un système similaire de "bunde".
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).
-
-
-
-
-
-
-
C'est nécessaire
Je suis toujours dégouté quand je vois comment Windows ou Linux sont beaucoup plus lent que BeOS sur des machines 10* plus rapide..
-
[+] [^]Vae Victis
Posté par gnap gnap (page perso, ) le 14/10/2005 à 19:08. (lien). Évalué à -8.BeOS c'est un système qui vit encore ? C'est bien beau de se masturber sur un machin mort. Il faut, des fois, pourtant, comparer ce qui est comparable. C'est à dire des systèmes qui marchent concrêtement, comme MS Windows ou GNU/Linux.
-
[^]Re: Vae Victis
Posté par eddine () le 14/10/2005 à 19:22. (lien). Évalué à 10.C'est fou comme les commentaires portent vite sous la ceinture qd certains n'ont d'autre argument que leur _avis_.
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 zero heure (Jabber id, page perso, ) le 14/10/2005 à 19:30. (lien). Évalué à 3.Tu as deja utilise BeOS ? tu peux expliquer ce que veut dire "marche concretement" ? BeOS tourne tres bien, on fait plein de trucs avec.
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.--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
-
[^]Re: Vae Victis
Posté par reno () le 15/10/2005 à 15:08. (lien). Évalué à 10.Je ne pense pas que le statut mort ou vivant de BeOS aie une importance pour faire une comparaison.
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 (page perso, ) le 16/10/2005 à 13:35. (lien). Évalué à 5.> 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..
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 () le 15/10/2005 à 15:52. (lien). Évalué à 4.Au passage, quel version/implementation de BeOS libre conseillerez vous aujourd'hui pour tester sur un PC moderne?
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 () le 15/10/2005 à 21:26. (lien). Évalué à 2.Il ne l'était pas et a l'heure actuelle, la reprise zéta ne l'est pas non plus.
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 (Jabber id, ) le 16/10/2005 à 07:46. (lien). Évalué à 1.Et d'une légalité douteuse..
-
[^]Re: Désolé mais BeOS != libre
Posté par tuiu pol (Jabber id, ) le 17/10/2005 à 12:04. (lien). Évalué à 1.Va falloir argumenter là ?!!
-
[^]Re: Désolé mais BeOS != libre
Posté par matlj (Jabber id, ) le 17/10/2005 à 14:17. (lien). Évalué à 5.Be Inc. s'est fait racheter par Palm Inc. et l'accord de vente portait sur toute la proprieté intellectuelle de Be.
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
-
-
-
-
-
Cela rassure
Voilà des gens qui font des choses vraiment utiles et qui sera appréciée par tous les utilisateurs.
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 gnap gnap (page perso, ) le 14/10/2005 à 19:10. (lien). Évalué à 5.« 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.
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 Khanh-Dang (page perso, ) le 14/10/2005 à 19:42. (lien). Évalué à 4.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...
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 () le 14/10/2005 à 21:49. (lien). Évalué à 9.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.
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 () le 14/10/2005 à 22:54. (lien). Évalué à 10.Oui, c'est ce que font les gens de kde-optimize à longueur d'année.
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 (page perso, ) le 15/10/2005 à 05:57. (lien). Évalué à 2.Je n'ai pas lu le fameux débat, mais vaut mieux ++i que i++ (en C et C++), c'est expliqué dans toutes les références dignes de ce nom, et c'est facilement compréhensible.
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.--
La liberté d'une personne s'arrête là où commence celle des autres.-
[^]Re: Cela rassure
Posté par Guillaume Knispel () le 15/10/2005 à 12:16. (lien). Évalué à 7.Je n'ai pas lu le fameux débat, mais vaut mieux ++i que i++ (en C et C++), c'est expliqué dans toutes les références dignes de ce nom, et c'est facilement compréhensible.
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 () le 18/10/2005 à 16:23. (lien). Évalué à 2.C'est pas tout a fait ca le probleme.
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 () le 18/10/2005 à 16:54. (lien). Évalué à 5.Mouaif, ça mériterait d'être vérifié, mais comme ça intuitivement je dirais que ce genre de micro-optimisation, gcc les fait déjà tout seul comme un grand. C'est pas bien dur de détecter quand la valeur de l'expression n'est pas utilisée, et donc de ne pas la stocker même pour un i++.
-
[^]Re: Cela rassure
Posté par Sebastien Binet () le 18/10/2005 à 17:31. (lien). Évalué à 5.Mouaif.
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 (Jabber id, page perso, ) le 19/10/2005 à 08:09. (lien). Évalué à 4.Question d'un néophyte : Quel est l'avantage de mettre la partie constante à gauche d'un == ?
-
[^]Re: Cela rassure
Posté par Aurélien Girard () le 19/10/2005 à 09:25. (lien). Évalué à 0.Se croire plus futé que son compilateur ?
-
[^]Re: Cela rassure
Posté par Sebastien Binet () le 19/10/2005 à 10:06. (lien). Évalué à 8.Ca permet au compilateur de te dire lorsqu'il y a un = qui est tombé, puisqu'il ne peut pas mettre le sens profond de l'Univers dans 42.
-
[^]Re: Cela rassure
Posté par bigben99 () le 20/10/2005 à 21:06. (lien). Évalué à 4.En plus clair, si tu oublies un = (erreur classique du débutant en C):
- 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 Khanh-Dang (page perso, ) le 21/10/2005 à 19:10. (lien). Évalué à 2.Et c'est pour ce genre de raisons que les langages comme Caml sont vraiment pas mal. En général, un code source en Caml qui compile est un code source qui fait ce qu'on a décidé. Une étourderie et ça ne compile plus.
-
[^]Re: Cela rassure
Posté par Aurélien Girard () le 24/10/2005 à 09:06. (lien). Évalué à 2.C'est un peu ce que promettait Ada ;)
-
-
[^]Re: Cela rassure
-
-
-
-
-
[^]Re: Cela rassure
Posté par Matthieu Moy (page perso, ) le 18/10/2005 à 19:31. (lien). Évalué à 2.Tout à fait, dans 95% des cas, ça ne changera rien.
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 (page perso, ) le 19/10/2005 à 07:10. (lien). Évalué à 1.Sur des classes avec surcharge d'opérateur, gcc n'optimisera pas ce type de code, sauf si tu déclares ta méthode en ligne, auquel cas le code à compiler contiendra directement les instructions (et pourra donc être optimisé).
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.--
La liberté d'une personne s'arrête là où commence celle des autres.
-
-
-
[^]Re: Cela rassure
Posté par Guillaume Knispel () le 19/10/2005 à 14:28. (lien). Évalué à 2.C'est bien ce que je dis... En C ça ne sert à rien vu que les compilateurs suppriment tous seuls comme des grands les stockages inutiles de valeurs antérieur.
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 () le 15/10/2005 à 13:39. (lien). Évalué à 4.Une mailing list équivalente vient d'être créée chez GNOME: http://mail.gnome.org/archives/desktop-devel-list/2005-Octob(...)
http://mail.gnome.org/mailman/listinfo/performance-list-
[^]Re: Cela rassure
Posté par Philippe Fremy (page perso, ) le 22/10/2005 à 08:09. (lien). Évalué à 4.Je trouve ca inquietant quand meme que ca ne soit que maintenant que Gnome se soucie d'optimisation. Si on peut gagner 24% en deux jours, c'est vraiment qu'il y avait des problemes faciles a resoudre qui n'ont jamais ete regarde.
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 (Jabber id, ) le 16/10/2005 à 21:26. (lien). Évalué à 7.C'est pour ça que des programmes comme Microsoft Word peinent (voire plantent) en ouvrant un document texte de quelques centaines de pages.
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"
-
-
[^]Re: Cela rassure
Posté par philip () le 14/10/2005 à 21:57. (lien). Évalué à 2.oui ça rassure ! peut être que gnome terminal va moins ramer... :)
c'est cool
j'aime les gnomes !-
[^]Re: Cela rassure
Posté par GnunuX (Jabber id, page perso, ) le 15/10/2005 à 06:44. (lien). Évalué à 4.En parlant de cela, voir le comparatif fait sur un test particulier entre gnome-terminal et xterm : http://mces.blogspot.com/2005/10/gnome-terminal-performance.(...) (vu sur http://planet.gnome.org il y a 2-3 jours).
-
[^]Re: Cela rassure
Posté par oliv () le 17/10/2005 à 16:25. (lien). Évalué à 1.Quelqu'un a testé avec aterm ? Il semble selon le lien que tu donnes que rxvt est le plus rapide (quoique quelqu'un mentionne konsole comme le plus rapide). Mon expérience est que aterm est plus petit et mieux que xterm, je serais curieux de voir ce qu'il vaut à ce jeu. Je testerai ce soir :)
-
[^]Re: Cela rassure
Posté par olivn () le 17/10/2005 à 19:08. (lien). Évalué à 0.aterm tout comme wterm (que j'utilise toujours) ne gèrent pas l'UTF-8.
Mais il vaut mieux avoir un un terminal très rapide et se passer de quelques fonctionalités.-
[^]Re: Cela rassure
-
-
[^]Re: Cela rassure
Posté par oliv () le 19/10/2005 à 07:14. (lien). Évalué à 2.ok, donc je me réponds...
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 () le 19/10/2005 à 07:48. (lien). Évalué à 3.Tiens, en parlant du choix du terminal idéal, un autre truc à prendre en compte, c'est ses capacités/fonctionnalités réelles. Perso c'est pas une question que je m'étais vraiment posée jusqu'à lire cette discussion, que j'avais trouvée vraiment très instructive :
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 () le 19/10/2005 à 09:33. (lien). Évalué à 0.Bizarre, j'ai fais le test chez moi avec xterm et gnome-terminal (fonte par défaut, bitmap je suppose?) et gnome-terminal et plus de 2 fois plus rapide que xterm...
-
[^]Re: Cela rassure
Posté par gpe () le 19/10/2005 à 09:45. (lien). Évalué à 1.Bon je le refais en un peu plus français.
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 () le 19/10/2005 à 10:05. (lien). Évalué à 2.En fonts bitmap, c'est aussi ce que j'obtenais. Ça dépend probablement de la version de gnome-terminal/vte/GTK/etc., de la taille du term, de la présence ou non d'une barre de défilement, tout ça quoi...
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
-
-
-
-
-
-
-
[^]Re: Cela rassure
Posté par tgl () le 16/10/2005 à 12:41. (lien). Évalué à 4.> peut être que gnome terminal va moins ramer
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 () le 16/10/2005 à 13:41. (lien). Évalué à 2.Mmmh... et un petit test de rxvt-unicode (urxvt) avec police TrueType en XFT met encore une claque à gnome-terminal + polices bitmap (~2x plus rapide, donc 16x plus que ce que j'utilisais à la base pour le même rendu). Bon bah je vais peut-être enfin changer de term finalement...
-
[^]Re: Cela rassure
Posté par durandal () le 16/10/2005 à 19:04. (lien). Évalué à 0.Oui enfin pour une utilisation normale d'un terminal la vitesse n'est pas aussi importante. Tu ne t'amuses pas à faire défiler des milliers de lignes dans un terminal tous les jours. Il faut juste trouver le bon compromis vitesse/beauté, et pour moi c'est Eterm. ;)
-
[^]Re: Cela rassure
Posté par tgl () le 16/10/2005 à 20:04. (lien). Évalué à 6.Bah... par exemple compiler un programme, ou bien même simplement se déplacer dans un gros fichier sous vim, c'est des utilisation "normales" d'un terminal, où ses performances font quand même une différence très perceptible.
Ç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 () le 16/10/2005 à 23:08. (lien). Évalué à 4.Pour compiler, un bon truc est d'ouvrir un autre tab dans le gnome-terminal et de laisser le focus sur celui pendant la compil; ainsi il s'amuse plus à tout afficher et cela va sensiblement plus vite.
-
[^]Re: Cela rassure
Posté par Guillaume Knispel () le 16/10/2005 à 23:56. (lien). Évalué à 5.Attention, on va bientôt croire qu'on est en train de lire la page trucs et astuces de 01net :P
-
[^]Re: Cela rassure
-
-
[^]Re: Cela rassure
Posté par durandal () le 20/10/2005 à 06:35. (lien). Évalué à 1.J'ai aussi fait quelques tests avec différents terminaux. Je ne m'attendais pas à de telles différences de performances, et c'est vrai que quand on met 20s sur un test là où d'autres terminaux mettent moins de 2s ça peut devenir vraiment problématique pour certains même pour une utilisation "normale" (une perte de temps d'une vingtaine de secondes toutes les 10000 lignes).
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
Il existe un outil idoine à sysprof mais en console, c'est OProfile: http://oprofile.sourceforge.net/about/ .
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 Binet () le 16/10/2005 à 09:42. (lien). Évalué à 1.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.
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 (page perso, ) le 17/10/2005 à 07:52. (lien). Évalué à 4.En même temps, c'est le cas pour pas mal de modules...
-
[^]Re: sysprof
Posté par Sebastien Binet () le 17/10/2005 à 08:23. (lien). Évalué à 3.Certes...
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 () le 16/10/2005 à 12:07. (lien). Évalué à 3.Quand sysprof-1.0 a été annoncé sur LKML, il y a eu une petite discussion sur ses mérites par rapport à oprofile :
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 ?
Habituellement, lorsqu'on développe, après avoir réfléchi à une belle architecture, on en vient forcément à réfléchir aux performances, non ?
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 ?
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.