Journal Vous trouvez GNOME lent ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
28
oct.
2005
Alors venez donner un coup de main.... Toujours dans l'optique d'optimisation évoquée ici [1] d'optimisation de GNOME, dimanche 30 octobre aura lieu le "Performance Love Day" . Cela durera au minimum de 14H00 à 3H00 UTC, soit à cause du passage à l'heure d'hiver, 15H00 à 4H00. Lisez [2] pour connaitre tous les détails.

Pour cela l'outil sysprof [3] est utilisé, qui permet de trouver les fonctions dans lesquelles le programme passe le plus de temps. Une action très simple est de juste lancer l'outil et le programme à analyser. Vous repérez les "goulets d'étranglement", et envoyer la trace générée par sysprof. Vous pouvez aussi aider à trier les bugs de performance sur le bugzilla.

Alors bonne chasse !

Attention, n'oubliez pas si vous utilisez Mandriva 2006 que vous avez une version de GNOME de retard (2.10 au lieu de 2.12). Il vaudrait mieux installer GNOME avec jhbuild [4] (compile GNOME à partir du cvs) ou garnome [5] (compile GNOME à partir des dernier paquets releasés)

[1] http://linuxfr.org/2005/10/14/19737.html
[2] http://live.gnome.org/GnomeLove_2fPerformanceLoveDay
[3] http://live.gnome.org/Sysprof
[4] http://www.gnome.org/~newren/tutorials/developing-with-gnome(...)
[5] http://cipherfunk.org/garnome/

  • # Heure

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

    15H00 à 4H00
    heure française, bien sûr, pardon aux autres francophones.

    • [^] # Re: Heure

      Posté par  (site web personnel) . Évalué à 7.

      heure métropolitaine, pardon aux français d'Outre-Mer :-)

      • [^] # Re: Heure

        Posté par  . Évalué à 7.

        C'est marrant quand je suis en Guyane ce sont les Français en "France hexagonale" qui sont "d'outre-mer" ... Question de point de vue ;)

        • [^] # Re: Heure

          Posté par  . Évalué à 7.

          Objectivement tu as raison, mais sans conventions c'est le bowdel.

  • # Attention : message sans intérêt

    Posté par  . Évalué à 4.

    Çà, c'est vraiment une bonne initiative, parce que GNOME est vraiment lourd et lent. Pourtant je l'utilise tous les jours, et n'en pense que du bien à part ces deux détails.

    Sans vouloir lancer un gros troll, c'est un excellent environnement de bureau mais pour ce que j'en vois (c'est-à-dire un peu plus que ce qui est visible sur l'interface graphique, mais pas beaucoup plus loin non plus), un Windows95 faisait déjà de même avec des ressources bien plus limitées (au prix, c'est vrai, d'un certain nombre de raccourcis assez sales).

    Je dis cela parce que la lenteur n'est pas le seul point noir de GNOME, sa sobriété toute relative en est également un car tout le monde ne travaille pas sur sa machine personnelle. Nous utilisons par exemple, au travail, des gros serveurs SUN Solaris de dernière génération, ayant adopté GNOME ¹, le tout attaqué par une batterie de terminaux X type thin client. Tous les bureaux GNOME des utilisateurs partagent la même machine. Je ne sais pas si GNOME sait en tirer parti ou pas ...

    ¹ : http://linuxfr.org/2001/05/23/3627.html

    • [^] # Re: Attention : message sans intérêt

      Posté par  (site web personnel) . Évalué à 6.

      Personnellement, je ne pense pas que sa sobriété soit un défaut... Et il a de grandes possiblités de personnalisation, donc... Et je préfère la sobriété pour travailler à un Windows XP ou KDE, beaucoup plus chargés et plus fatiguant à la longue (avis personnel). Après le look dépend aussi de ton distributeur.

      Quand à tes thin clients, il me semble que les bibliothèques sont chargées en mémoire sur tes serveurs, donc chargées une seule fois pour tous les clients. GNOME ou pas, je crois que cela n'a pas de rapport.

      • [^] # Re: Attention : message sans intérêt

        Posté par  . Évalué à 4.

        Les données des logiciels et bibliothèques ne sont bien évidemment pas partagées entre tous les clients. Je doute que quand Gnome utilise X Mo de RAM, il s'agit de X Mo de code... (le code est loin d'être majoritaire à mon avis).

        • [^] # Re: Attention : message sans intérêt

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

          Tout à fait, c'est pour ça qu'en général ces bécanes sont assez caustaudes en RAM... Il y avait eu un article récemment ici sur un cas concret de mise en oeuvre de thin clients sous debian, mais je sais plus où...

      • [^] # Re: Attention : message sans intérêt

        Posté par  . Évalué à 2.

        Quand je parlais de sobriété toute relative, je voulais bien entendu parler de sa voracité en RAM et en ressources diverses. Pour les thèmes graphiques, GNOME n'a désormais plus rien à prouver, bien sûr.

      • [^] # Re: Attention : message sans intérêt

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

        Un Windows XP correctement dégraissé est bien agréable et pas loin de la "sobriété" de Windows 95, mais ce n'est pas livré ainsi par défaut. Quant à KDe, j'ignore si on peut lui faire perdre ses rondeurs dans les mêmes proportions...

  • # [GNOME 2.12 sous 2006.0] dispo pour utilisateurs club Mandriva

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

    Ceux qui possèdent une Mandriva 2006 et sont adhérants au club ont la possibilité d'installer Gnome 2.12. En effet celui-ci est disponible dans un nouveau média crée pour le club qui aura des backports de cooker.
    Plus d'info : http://club.mandriva.com/xwiki/bin/Main/Gnome212Rpms

    sinon vous pouvez suivre ce blog qui est très intéressant : http://primates.ximian.com/~federico/news-2005-10.html#27

  • # Il y a du travail de fait

    Posté par  . Évalué à 5.

    À noter le travail de Lorenzo Colitti :
    http://www.gnome.org/~lcolitti/gnome-startup/analysis/

    En résumé il a réussi à gagner 17 secondes au démarrage de Gnome. Il a fait une liste de patch dont certains ont déjà été intégrés.

    Dans son travail, il apparait surtout que pour des raisons de compatibilité, gconf2 n'est pas optimisé. En cassant la compatibilité de gconf2 avec les Gnome avant 2.6, il gagne 7 secondes !!!

    Reste à espérer que tout son travail soit propre pour être accepter dans la version 2.14 de Gnome.

    • [^] # Re: Il y a du travail de fait

      Posté par  . Évalué à -2.

      \o/

    • [^] # Re: Il y a du travail de fait

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

      En même temps, il faut se rappeler que ces 17 secondes dépendent de la bécane qui fait tourner GNOME... Ici c'est un Dell Latitude D400:
      Processor: Intel Pentium M, 1400 MHz
      Memory: 512 MB 266 MHz DDR SDRAM

      • [^] # Re: Il y a du travail de fait

        Posté par  . Évalué à 1.

        Si j'ai bien compris, la principale perte de temps se fait à attendre les données du disque dur.

        Ce que propose Colitti, c'est charger les certaines librairies importante (Gtk) entièrement au début plutôt que de le faire petit à petit, c'est aussi de lire toute la conf gconf en une fois et la parser petit à petit, etc...

        Donc, je ne pense pas que son processeur ou sa RAM ne joue vraiment. Par contre, son disque dur (Toshiba MK3021GAS 30GB, 4200 RPM hard disk) est vraiment lent. Je ne sais pas combien de temps il est possible de gagner sur un PC de bureau avec un disque dur à 7200RPM.

        Mais bon, même 5 ou 10 secondes de gagnés, c'est déjà ça de pris...

        • [^] # Re: Il y a du travail de fait

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

          Exact, je m'en suis rendu compte juste après avoir validé mon post, mais j'ai eu la flemme de rajouter la précision. ça m'apprendra ^_^.

          Pour gconf, un des problèmes, c'est que c'est fait en plein de petits fichiers, ce qui augmente les temps de lecture. ça fait un petit moment qu'on sait que ce sont les accès disque qui sont le goulot d'étranglement (déjà évoqué lors du GUADEC 2005) par Robert Love:
          A LIRE ABSOLUMENT !

          http://rlove.org/talks/rml_guadec_2005.sxi

          Ces deux phrases résument le problème :
          As processor speeds increase, I/O wait time approaches 100% of total time!

          Conclusion: Splattering files all over disk is bad; subdirectories are better; all in same directory good; single file best

          Ce qui fait que plein de petit fichiers pour gconf entraine des performances catastrophiques...

          • [^] # Re: Il y a du travail de fait

            Posté par  (Mastodon) . Évalué à 2.

            Si j'ai bien compris ce que disait le monsieur qui a fait le Summer of Code sur ce sujet, si on n'utilise pas de Gnome <= 2.6, on peut déjà profiter de ce gain en appelant gconf-merge-tree sur /etc/gconf/gconf.xml.defaults.

            Je l'ai fait il y a quelques temps, mais je n'ai pas senti de grosse amélioration. Certainement rien de l'ordre des 10 secondes, et pourtant j'ai un disque dur à 4200 rpm. Quelqu'un a essayé et a eu des résultats positifs ?

          • [^] # Re: Il y a du travail de fait

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

            Il faut savoir que Enlightenment (17) démarre en moins d'une seconde (si on désactive l'animation de chargement totalement inutile, mais tellement belle ...). Ils ont choisi d'utiliser un format binaire très optimisé justement pour des questions de performance : fichiers plus petits et plus rapide à parser.

            Résumé en une phrase :
            E17 uses binary config files. They have very little read/write overhead, so there is no no CPU wastage on parsing etc.

            Plus d'info ici :
            http://get-e.org/Main/FAQs.html#8

            Haypo

            • [^] # Re: Il y a du travail de fait

              Posté par  . Évalué à 3.

              Ca ne risque pas d'être une horreur à intégrer pour les distros?
              Et les thèmes seront ils faciles à faire ou faudra t il avoir quelques années de programmation dans les pattes?

  • # autre optimisation

    Posté par  . Évalué à 3.

    Autre optimisation possible d'apres l'un des dev sur le planet gnome (je ne sais plus lequel), serait d'arreter d'utiliser GList a tout va et d'utiliser des tableaux a la place.

    Les GList sont des listes chainees, donc les temps d'acces sont longs. Avec un tableau (un hash quand on veut une taille variable), on accede directement a l'element qu'on cherche.

    • [^] # Re: autre optimisation

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

      C'est seulement vrai sur les listes avec beaucoup d'éléments: tu passes plus de temps à parcourir la liste qu'autre chose. Le temps d'accès à un élément dépendra de sa position dans la liste: si c'est le premier ce sera très rapide (plus que les tableaux il me semble), si c'est le dernier ce sera très long. Les tableaux par contre sont assez lents d'accès, mais ce temps d'accès est constant.

      <<corrigez moi si je dis une bêtise>>

      • [^] # Re: autre optimisation

        Posté par  (site web personnel) . Évalué à 4.

        Tu dis une bétise... en tout les cas pour le C (et aussi java). En C, un tableau c'est le pointeur vers le premier élément... tu fais ++ à ton pointeur et tu es sur le deuxième élément... y a pas plus rapide comme accès.

      • [^] # Re: autre optimisation

        Posté par  . Évalué à 6.

        La difference de base entre un tableau et une liste chainee, c'est que le tableau est une zone contigue de la memoire alloue une seule fois, a la creation du tableau, alors que dans une liste chainee on alloue la memoire quand on en a besoin.

        Par consequent, si on veut l'element no 100 d'un tableau, on a juste a incrementer la valeur du pointeur de 100. On sait ou va se trouver l'element dans la memoire. A l'inverse, une liste chainee c'est un ensemble de paire (donnees, pointeur suivant). Donc on est oblige de suivre la liste du debut jusqu'a l'element voulu pour arriver jusqu'a l'element qu'on cherche.

        Le probleme des tableaux, c'est que la taille est fixe. Forcement, vu que c'est une zone memoire contigue, si on ecrit des choses derriere on ne peut pas agrandir le tableau.

        La solution hybride c'est les tables de hachage. Un gros, c'est un tableau de listes chainees.

        Exemple: on veut classer des mots. On fait un tableau de 26 cases avec les lettres de l'alphabet (a, b, c, d, e...). A chaque lettre est associee une liste chainee. Et si on veut classer le mot "troll" (ou le rechercher), on va directement au "t" puis on parcours la liste chainee pour trouver le mot (ou l'inserer par ordre alphabetique).

        Bien sur, une telle table de hachage n'est pas tres bonne parce qu'on va avoir beaucoup de collisions (cad: d'elements inseres dans la meme liste chainee). Dans l'ideal on ne doit avoir que quelques elements par liste, pour que l'acces soit plus rapide.

        • [^] # Re: autre optimisation

          Posté par  (site web personnel) . Évalué à -1.

          La difference de base entre un tableau et une liste chainee ...

          Il me semblait également qu'un tableau permet un acces aléatoire alors qu'une liste chainée ne permet qu'un acces sequentiel ?

        • [^] # Re: autre optimisation

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

          Ok, ça me parraissait étonnant, mais c'était des vieux souvenirs de cours (pas très frais on dirait). Donc si j'ai bien compris pour choisir entre liste chainée, tableau ou table de hachage, c'est surtout une question de compromis entre rapidité et empreinte mémoire, et savoir si ton nombre d'éléments à stocker est variable...

          • [^] # Re: autre optimisation

            Posté par  (Mastodon) . Évalué à 4.

            Ça dépend aussi du type d'opérations que tu vas faire sur tes données. Si tu fais beaucoup d'accès aléatoires, un tableau est définitivement plus rapide. Par contre si tu déplaces beaucoup les éléments, la liste chaînée est meilleure:

            Imaginons ce tableau, dans lequel je veux déplacer 6 en première place
            1 2 3 4 5 6 7
            Je dois d'abord déplacer 1, 2, 3, 4 et 5 d'un cran vers la droite, puis placer 6 en première place. Si j'avais eu une liste (simplement) chainée, j'aurais juste eu à faire:
            5.suivant = 7
            6.suivant = 1
            liste.premier = 6

            • [^] # Re: autre optimisation

              Posté par  . Évalué à 1.

              Je pense aue dans le cas des GList trop utilisé, ca peut venir du fait que les gens veulent une liste de taille non fixe.

              C'est plus un probleme d'API que de savoir si tel ou tel structure de donné est plus efficace.
              Idealement (glib, java, C#, mono,c++...) je m'attend a avoir un objet de type Liste qui offre une interface simple et clair.

              Ensuite il peut y avoir autant de specialisation possible que l'on veut,
              l'implementation par default devrais etre la plus rapide en moyenne.
              Si on ne fait pas de deplacement dans la liste, on prend un truc du genre liste chainé de tableau, arbre de tableau , ...

              dans le cas de la Glib et d'apres les commentaires des gens qui ont regardé le mauvais usage de la GList, c'est que les dev ne lisent pas la doc, la doc n'est pas assez clair, l'API devrais etre repensé.

              • [^] # Re: autre optimisation

                Posté par  (Mastodon) . Évalué à 4.

                Au passage, la GLib propose GArray, qui est un tableau extensible, et pourrait certainement remplacer les G(S)List dans de nombreux cas.

                je m'attend a avoir un objet de type Liste qui offre une interface simple et clair.
                Ensuite il peut y avoir autant de specialisation possible que l'on veut


                Le problème si on a une seule interface commune aux différents types de données, c'est qu'on va être obligé de définir toutes les opérations pour tous les types, même quand une opération est très coûteuse.

                Par exemple on va avoir une opération "obtenir l'objet précédent" qui sera disponible aussi dans les GSList, malgré le fait que ce soit une opération très coûteuse dans une GSList (on doit parcourir la liste), et très peu coûteuse dans une GList ou GArray (accès en temps constant).

                Actuellement, GSList ne propose pas cette opération. Donc si j'ai besoin d'obtenir l'objet précédent, plusieurs cas se présentent:
                - j'adapte mon algo pour avoir toujours un pointeur sur l'objet précédent, et donc c'est bien mieux qu'avoir utilisé une fonction générique
                - je code une fonction générique, et j'ai une bonne chance de me rendre compte que c'est mauvais
                - j'utilise un type de données plus adapté, comme une GList.

                Au final, même si l'on masque les spécificités des types de données dans une interface commune, on a quand même besoin de savoir ce qui est utilisé derrière si on veut être efficace.

                • [^] # Re: autre optimisation

                  Posté par  (site web personnel) . Évalué à 1.

                  tu fais un gros

                  throw new UnsupportedException("send a patch");

                  :)

                • [^] # Re: autre optimisation

                  Posté par  . Évalué à 3.


                  Au final, même si l'on masque les spécificités des types de données dans une interface commune, on a quand même besoin de savoir ce qui est utilisé derrière si on veut être efficace.


                  d'ou ma remarque d'utiliser par defaut des listes qui sont performantes en moyenne, comme, au pif, des listes doublement chainé.

                  Le mechanisme proposé permet justement de pouvoir choisir ce qui est utilisé derriere SI on veut etre efficace.

                  Actuellement il faut connaitre les details de l'implementation derriere, ses limites,...etc. avant de l'utiliser, et ca c'est mal.
                  Quand j'utilise une API je m'attend a avoir un truc qui me simplifie la vie, ensuite si je sait que mon programme doit en moyenne augmenter ses donnés de 200 élements, j'ai pas envie de changer tout mes types a chaque fois, l'API devrait me permettre de la regler.

                  De plus les exceptions, ca peut servir a gérer ce genre de truc, meme si c'est ca pourrais etre plus propre:
                  - un objet de base
                  - une interface si besoin est pour des propriété particulière
                  - des itérateurs
                  Enfin Cf les vecteurs en java,

                  il suffit de faire une GList abstraite et que le dev choissisent une implementation precise.

                  • [^] # Re: autre optimisation

                    Posté par  (Mastodon) . Évalué à 3.

                    On est d'accord qu'il y a mieux "en général" qu'une liste simplement chaînée, par exemple des listes de tableaux. Mais il n'y a pas de structure qui soit bonne "en général", et qui permette d'éviter de se demander quoi choisir. Si ça existait, tu penses bien que tout le monde l'utiliserait :)

                    L'approche la plus propre que je connaisse est celle de la STL, où effectivement dans de nombreux cas on peut changer la structure de données sans changer le code, mais là non plus on n'est pas dispensé de savoir choisir entre les différents types de données. Et si tu choisis le mauvais type et que tu fais un algo en fonction de ce type, tu devras quand même réécrire ton code si tu changes d'avis.

                    Ce que je veux dire, c'est que tu peux abstraire autant que tu veux tes types de données, au moment de coder l'algo tu es obligé de savoir des choses basiques comme:
                    - Je peux parcourir mes éléments séquentiellement ou pas ?
                    - Je peux accéder à un élément n'importe où ou pas ?
                    - Je peux parcourir dans les deux sens, ou dans un seul ?
                    - Je peux déplacer des éléments ou pas ?
                    - Je peux stocker beaucoup de données ou pas ?
                    (Pour toutes ces questions, il faut bien sûr penser "en temps et en espace raisonnables", sinon la réponse est toujours oui)

                    Et même si ton API te fournit le même ensemble de fonction pour tous les types, ça ne veut pas dire que ces fonctions sont efficaces.

                    Par exemple si tu utilises comme abstraction des iterateurs, ton API ne te donnera pas d'iterateur qui puisse se déplacer dans les deux sens pour une liste simplement chaînée. Ou bien si elle te fournit un iterateur qui le fait, il sera très lent.

                    Pareil pour les listes doublement chaînées, tu auras sûrement une fonction "obtenir l'élément à la position i", mais cette fonction sera lente. Donc si tu veux être efficace, quoi qu'il arrive, tu devras connaître les limites du type de données que tu manipules.

                    (Après, savoir si ça vaut le coup de se casser la tête pour choisir le bon type de données, c'est un autre problème. Dans beaucoup de cas, utiliser un Vector en Java sera très acceptable. Mais si tu as besoin d'être efficace, pas le choix)

                    • [^] # Re: autre optimisation

                      Posté par  . Évalué à 1.

                      Je suis globalement d'accord,
                      Je ne dis pas que l'API doit fournir une classe liste quifaittout, je dis que l'API doit fournir une abstraction, avec plusieurs niveau si nécessaire,

                      et si l'API propose une implémentation par defaut (GDefaultList), peut etre prendre un truc vaguement générique, facilement changeable.

                      Ensuite pour avoir des programmes quitorche, c'est encore mieux si l'API a un flag profiling pour voir les statistiques d'utilisations des fonctions, avec des infos utiles (nombre d'elements, .. toussa).

                      Je pense que les cas ou l'on recherche l'optimisation est bien plus faible que les cas ou on veux juste une liste.

                      Sinon je suis allé voir la doc de la GLib et les type proposé sont trop spécialisé (i.e il manque le vecteur de java).
                      Si on veut utiliser la Glib, il n'y a pas vraiment une liste a tout faire avec performances correcte.

                      Le plus proche est le GArray, mais ca ressemble a un tableau avec du realloc, eventuellement avec de la préalocation,
                      pas des trucs du genre <truc tres opaque> avec une API type tableau,
                      par ex partitioner l'espace des index dans un arbre a arité fixe, le tout paramétrable, avec de bon defaut.

                      Ensuite si on veut s'amuser en C on peut commencer a mettre les donnés de liste dans la structure a stocker, et stocker des offset dans une strucuture de type liste.



















                  • [^] # Re: autre optimisation

                    Posté par  . Évalué à 3.

                    Les listes doublement chaînées ne sont pas « efficaces en moyenne ».

                    Pour rechercher si un élément est dans ta liste, tu dois forcément
                    parcourir ta liste ce qui est linéaire alors qu'avec un arbre binaire,
                    c'est en temps logarithmique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.