Rendre GNOME rapide

Posté par  (site Web personnel) . Modéré par Florent Zara.
Étiquettes :
0
14
oct.
2005
Gnome
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 ! 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

  • # Effectivement

    Posté par  . Évalué à 0.

    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  . É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  . É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  . É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  . Évalué à -8.

        voila une idée qu'elle est bonne !!!!
      • [^] # Re: Effectivement

        Posté par  . É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  . É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  . Évalué à 3.

            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

          Posté par  (site Web personnel) . Évalué à 2.

          C'est un des points qu'ils comptent bientôt optimiser aussi...
    • [^] # Re: Effectivement

      Posté par  . É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  (site Web personnel) . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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  (site Web personnel) . É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  . Évalué à 5.

                  Muine! Prise en main d'un non-geek: 30 secondes.
                • [^] # Re: Effectivement

                  Posté par  . É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  . É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  (site Web personnel) . Évalué à 4.

                  beep media player, rhythmbox, amarok, totem, muine, banshee, juk, mpd + un bon client (il yen a :), etc.
              • [^] # Re: Effectivement

                Posté par  . É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  . É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  (site Web personnel) . É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  . É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  (site Web personnel) . É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  . É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  . É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  . É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  . Évalué à 0.

          on ne dit pas "teinte" mais "contamine".
          • [^] # Re: Effectivement

            Posté par  . É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  . É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  . Évalué à 4.

      z'ont pas d'humour les moinsseurs ;-)

      Pascal
  • # bla bla bla bla bla bla bla bla bla bla

    Posté par  (site Web personnel) . Évalué à -10.

    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  (site Web personnel) . É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  . É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  (site Web personnel) . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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).

                    BeOS le faisait il y a 20 ans !

  • # C'est nécessaire

    Posté par  . Évalué à 9.

    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  (site Web personnel) . É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  . É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  (site Web personnel) . É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.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Vae Victis

        Posté par  . É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  (site Web personnel) . É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  . É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  . É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  . Évalué à 1.

          Et d'une légalité douteuse..
          • [^] # Re: Désolé mais BeOS != libre

            Posté par  . Évalué à 1.

            Va falloir argumenter là ?!!
            • [^] # Re: Désolé mais BeOS != libre

              Posté par  . É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.
  • # Cela rassure

    Posté par  . Évalué à 10.

    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  (site Web personnel) . É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  . É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  . É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  (site Web personnel) . É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  (site Web personnel) . É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.
          • [^] # Re: Cela rassure

            Posté par  . É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  . É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  . É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  . É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  (site Web personnel) . Évalué à 4.

                    Question d'un néophyte : Quel est l'avantage de mettre la partie constante à gauche d'un == ?
                    • [^] # Re: Cela rassure

                      Posté par  . Évalué à 0.

                      Se croire plus futé que son compilateur ?

                      BeOS le faisait il y a 20 ans !

                    • [^] # Re: Cela rassure

                      Posté par  . É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  . É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  . É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  . Évalué à 2.

                            C'est un peu ce que promettait Ada ;)

                            BeOS le faisait il y a 20 ans !

                        • [^] # Re: Cela rassure

                          Posté par  . Évalué à 2.

                          Oui enfin avec gcc tu es de toutes façons averti (à moins de mettre des parenthèses autour d'une affectation dans un test).
                • [^] # Re: Cela rassure

                  Posté par  (site Web personnel) . É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  (site Web personnel) . É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.
              • [^] # Re: Cela rassure

                Posté par  . É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  . Évalué à 4.

          • [^] # Re: Cela rassure

            Posté par  (site Web personnel) . É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  . É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"

        *Sano*

    • [^] # Re: Cela rassure

      Posté par  . É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  (site Web personnel) . É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  . É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  . É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

              Posté par  . Évalué à 6.

              Ben, pas quand tout le système utilise UTF8, sinon, ça doit être galère :(
          • [^] # Re: Cela rassure

            Posté par  . É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  . É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  . É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  . É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  . É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

                    Posté par  . Évalué à 1.

                    Moi c'était en Gnome 2.10 avec des terminaux en 80x25 avec barre de scroll. Pour le xterm c'est celui de Debian Testing je ne sais plus quelle version c'est.
                    Pour les polices c'étai les polices standards.
      • [^] # Re: Cela rassure

        Posté par  . É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  . É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  . É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  . É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  . É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  . É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

                  Posté par  . Évalué à 6.

                  Je suis d'accord bien que des workaround y'en a tout plein et qu'ils sont pas franchement compliqués, mais voilà, ça me gonfle d'avoir à y penser. Je préfère voir le problème réglé une fois pour toute que de le contourner quotidiennement.
              • [^] # Re: Cela rassure

                Posté par  . É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

    Posté par  . Évalué à 6.

    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  . É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  (site Web personnel) . Évalué à 4.

        En même temps, c'est le cas pour pas mal de modules...
        • [^] # Re: sysprof

          Posté par  . É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  . É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 ?

    Posté par  . Évalué à -8.

    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 ?

      Posté par  (site Web personnel) . Évalué à 3.

      il y a effectivement des devs qui pensent comme ca, ca donne e17.
      Certes c'est tout plein d'effets, mais ca met un max de temps a sortir ! :(
    • [^] # Re: Comment font-ils leurs tests ?

      Posté par  (site Web personnel) . Évalué à 5.

      d'un autre coté en général on s'attache à faire marcher le bouzin et ensuite une fois que ça marche correctement, on optimise.

      En tout cas, je vois les choses comme ça...

      http://damien.pobel.fr

    • [^] # Re: Comment font-ils leurs tests ?

      Posté par  . Évalué à 8.

      En l'occurence il s'agit bien de divers petits hacks d'optimisation (comme ajouter un cache par ci, court circuiter par là ...) pas d'un refactoring (changement structurel).

      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 à ceux qui les ont postés. Nous n’en sommes pas responsables.