Journal Performance des navigateur web: linux parent pauvre ?

Posté par .
28
12
déc.
2009
Cher tous,

À la suite des deux journaux récents sur Chrome [1] et sur Firefox [2], j'ai décidé de me faire un petit panorama personnel des performances des navigateurs web disponibles sous Linux, dans leurs versions linux (Kubuntu 9.10) et dans leurs versions windows (Vista). Pour ce faire, j'ai utilisé les benchmarks PeaceKeeper [3] et SunSpider [4], qui valent ce qu'ils valent, et qui ont tourné sur un Intel Q9300 (quad core 2.53Ghz).

Ont été testés: Firefox 3.5.5 (Linux/Windows), Swiftfox [5] (Linux) et Swiftweasel [6] (Linux), Chromium 4.0.269 (Linux/Windows), Chrome 3.0 (Windows).

Voilà les résultats sous Linux:

PeaceKeeper SunSpider
Firefox 1330 2549
Swiftweasel 1530 2140
Swiftfox - 1141
Chromium - 476

Commentaire rapide: sur ces tests, Firefox est à la ramasse par rapport à Chromium. Il est 5.3x plus lent que Chromium sur le benchmark Sunspider. Les deux versions "optimisées" de Firefox, Swiftweasel et Swiftfox apportent leur lots d'amélioration, mais à ce petit jeu là, Swiftfox se démarque très nettement en étant 2.6x plus rapide que son papa, là où Swiftweasel ne gagne "que" 20%. Qu'on ne me dise pas que ces différences sont visibles uniquement dans les benchmarks: que les sceptiques utilisent des sites lourds (genre Wave) avec Firefox et Chromium, et ils verront que dans le premier cas, ce n'est quasi pas utilisable, alors que dans le second ça le devient.

D'autre part, que; est donc le secret de fabrication de Swiftfox ? Il semble malheureusement que les binaires sont propriétaires, et puisque d'après le patch disponibles sur le site officiel [7], les changements sur les sources semblent mineurs, je ne vois que les options de compilations pour expliquer les différences. Pour ma part, j'ai essayé en -O3, et ça n'a pas changé grand chose. Comment fait donc l'auteur pour faire de ses binaires des Firefox de course, comparativement à la version "normale" ? Si c'est un secret, il gagnerait à être connu. Si ce n'est pas un secret, pourquoi est-ce que les distribs ne font pas les packages de la même façon que lui ?

En plus, ce serait pratique de pouvoir recompiler Swiftfox, car il n'est disponible qu'en 32 bits (même les packages AMD64 sont en fait des x86), ce qui fait qu'il est impossible de lui faire partager les plugins avec un firefox x86_64 existant (utilisable avec la version alpha de Flash x86_64 [8]). Pas glop pour passer de l'un à l'autre, puisqu'il faut réinstaller pas mal de truc.

J'aurai pu m'arrêter là, et ça aurait déjà fait un joli journal, mais je suis allé jusqu'à rebooter sous windows pour tester y Firefox, Chrome et Chromium. Et là, quelle surprise !!!

PeaceKeeper Sunspider
Firefox 2062 1095
Chrome 3574 497
Chromium 4649 441

Sur le test Sunspider Firefox est 2.6x plus rapide sous Windows que sous Linux, alors que Chrome et Chromium propose grosso modo la même performance, excellente, sous les deux environnements, et que cette dernière a été pas mal améliorée entre Chrome (3.0) et Chromium (4.0, daily build). Bref: Google continue - largement - la course en tête.

Quelques questions:

Q1: Est-ce que ça ne vous pique pas les yeux de voir que Firefox sous Linux semble être vraiment à la traine par rapport à la version windows ?

Q2: Savez vous ce qui explique cette différence pharamineuse ?

Q3: Comment compiler Firefox Linux de façon à le hisser à la hauteur de Swiftfox (aka où trouver le mozconfig) ?

Q4: Dans un contexte ou globalement, 1/ le Web a de plus en plus importance et 2/ les sites stressent de plus en plus les navigateurs, comment expliquer que Mozilla, qui est l'un des portes drapeaux de l'open source, n'apporte pas le même soin au versions Linux qu'aux versions windows, alors que le "don't be evil" Google respecte les uns et les autres (!).

Q5: La question posée en "Pourquoi Chromium est il si rapide sous Linux ?" [9] se transforme plutôt en "Comment est-ce possible que Firefox sous Linux soit à ce point lent par rapport à la version Windows". Là, qu'on ne dise pas que c'est lié à une implémentation bloated ou je ne sais pas quoi...

Voilà... si quelqu'un peut éclairer ma lanterne, ça m'intéresse - et certainement pas que moi.

À vot' bon cœur.

Aurel.

PS: je me suis limité à ces quelques navigateurs, mais si vous voulez en tester d'autres et mettre les résultats dans les commentaires, n'hésitez pas, ce journal n'est pas sectaire :)

[1] https://linuxfr.org//~Duncan_Idaho/29132.html
[2] https://linuxfr.org//~plume/29135.html
[3] http://service.futuremark.com/peacekeeper/index.action
[4] http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
[5] http://getswiftfox.com/
[6] http://swiftweasel.tuxfamily.org/
[7] http://getswiftfox.com/source.htm
[8] http://labs.adobe.com/technologies/flashplayer10/64bit.html
[9] https://linuxfr.org//~manatlan/28092.html
  • # et m.... les fautes...

    Posté par . Évalué à 8.

    bon voilà, c'est dit... vous pouvez moinssez ce commentaire et essayer de passer aux dessus de ces dernières à la lecture du journal....
    • [^] # Re: et m.... les fautes...

      Posté par . Évalué à 6.

      Et j'ai oublié de dire que la version de swiftweasel testée est swiftweasel-3.5.5_intel-pgo_x86_64_ubuntu-9.10.tar.gz , c'est à dire que dans la course à l'optimisation, la cartouche PGO est déjà grillée.
      • [^] # Re: et m.... les fautes...

        Posté par . Évalué à 10.

        comme je ne savais pas ce ue signifiait PGO, voici le résultat de quelques recherches : PGO est l'acronyme de "Profile-Guided Optimization", c'est -à-dire que le programme est compilé une première fois avec des options de traçage d'exécution, puis exécuté sur une série de tests représentatifs de l'utilisation courante du programme, puis recompilé en tenant compte de ces informations.

        ça permet notamment que le compilateur se concentre sur les blocs de code les plus fréquemment utilisés, en connaissant leur utilisation (par exemple faut-il dérouler les boucles ou non ?), de bien placer en mémoire les blocs de code en fonction des branches prises afin d'optimiser les accès mémoire (si le test du if est fréquemment faux, il vaut mieux placer le code du else directement à la suite du if, afin qu'il soit déjà en large partie dans le cache), etc. etc.
  • # Linux parent pauvre du fait de part de marché

    Posté par (page perso) . Évalué à 0.

    Linux est très utilisé sur les serveurs, mais pas besoin de navigateur web sur un serveur.
    Reste alors les postes clients, et la c'est la débandade : 1-2% de part de marché.

    Et forcement, quand on développe, je trouve compréhensible qu'on essaye d'optimiser et qu'on fait des tests pour la majorité de nos utilisateurs, et on laisse un truc qui marche mais pas optimisé pour la minorité.

    Ensuite, si tu veux que Firefox soit optimisé pour ton OS chéri, tu peux aussi donner (soit du temps de développement, soit de l'argent pour que quelqu'un d'autre s'y colle) pour montrer que tu y tiens à cette optimisation... Mais force est de constater que l'argent rentre par la version Windows, donc que Mozilla met le focus sur la version Windows, et c'est logique : on compile sous Linux, bon on voit que ça rame, ben on laisse ça pour plus trad quand il y aura un business model Linux (il y en a un, les linuxiens sont de très bon prosélytistes, mais à priori faire une version non optimisée a l'air suffisant pour ça).

    Pour Chronium, c'est peut-être "par chance" que ça tourne bien sous Linux, c'est peut-être un marché de niche que Google veut prendre, c'est peut-être qu'il ont une force de frappe plus forte, on sait pas trop.
    • [^] # Re: Linux parent pauvre du fait de part de marché

      Posté par . Évalué à 10.

      Tu veux dire par là que les optimisations faites sur la version windows touchent uniquement le code spécifique à windows ? Ou alors qu'elles ne sont pas transférer dans la branche Linux ?

      Quoiqu'il en soit, je doute de cette explication, car sinon comment expliquer que Swiftfox sous Linux soit presque aussi rapide que la Firefox Windows ? Il n'utilise pas du code spécifique à windows, quand même ?

      Concernant Chromium: la stratégie de Google avec Chrome semble être de produire en interne le browser dont leurs sites web ont besoin, histoire d'accélérer un peu une maturation qui peut leur permettre de prendre tout le monde de vitesse dans le domaine du cloud computing avec Chromium OS. Ils ont donc les ressources, la matière grise, et une motivation résultat de leur stratégie globale, où le browser est un élément crucial.
      • [^] # Re: Linux parent pauvre du fait de part de marché

        Posté par (page perso) . Évalué à 4.

        Je propose une explication, ce n'est pas forcement la bonne, elle peut être invalidée dès que tu trouves la réponse à la question de la non prise en compte des optimisations de Swiftfox. Peut-être que les optimisations sont trop agressives et ne passent pas les contrôle qualité, et que la qualité est plus importante que l'optimisation, qui sait...
      • [^] # Re: Linux parent pauvre du fait de part de marché

        Posté par . Évalué à 5.

        Concernant Chromium: la stratégie de Google avec Chrome semble être de produire en interne le browser dont leurs sites web ont besoin, histoire d'accélérer un peu une maturation qui peut leur permettre de prendre tout le monde de vitesse dans le domaine du cloud computing avec Chromium OS. Ils ont donc les ressources, la matière grise, et une motivation résultat de leur stratégie globale, où le browser est un élément crucial.

        Oui, et à propos de Mais force est de constater que l'argent rentre par la version Windows, donc que Mozilla met le focus sur la version Windows, et c'est logique, il ne faut pas oublier que le bailleur de fonds de la mozfo c'est google, donc l'argent ne vient pas "de la version windows". Donc le bailleur de fonds était bien intéressé à ce que la version linux tourne aussi bien que la version windows, mais pas la mozfo apparemment.
        Si on additionne ça au fait qu'ils avaient abandonné mozilla embedded il y a longtemps pour le reprendre que récemment, je pense que ça veut dire que la mozfo n'a pas vu venir à ce moment là la convergence entre les petits embarqués et le pc, et donc le "cloud", et n'a pas vu alors l'importance d'avoir une version rapide sous linux pour ces matériels.

        L'autre coté des choses c'est qu'un firefox bien modifié avec de bonnes extensions reste beaucoup plus pratique même plus lent sous linux, que chrome. Donc la mozfo a vraiment la possibilité de rectifier le tir et de conserver son avance. Mais ça dépendra d'une part du nombre de gens en utilisateurs et en clients de l'embarqué qui sont intéressés par cet aspect des choses, et d'autre part de la stratégie du bailleur de fonds.
        Combien de temps google aura t il besoin d'eux? Pourquoi financent ils la mozfo?

        -Pour niquer IE, ça c'est sur.
        -Comme laboratoire expérimental pour leur chrome, probablement.. Avaient ils carrément l'intention de récupérer firefox un jour pour eux? Pourquoi ne l'ont ils pas fait?
        -Comme concurrence controlée qu'on peut ressortir lors d'un procés anti trust, probalement aussi.
        -...?

        Combien de temps tout ça vaudra 80 000 000$?
        • [^] # Re: Linux parent pauvre du fait de part de marché

          Posté par . Évalué à 4.

          Les besoins de Google et Mozilla sont tres differents :

          - Google construit un OS base sur Linux, avoir des perfs excellentes la dessus est donc essentiel pour eux
          - MoFo recoit ses fonds selon la part d'utilisation de son browser en gros, pour grossir ses parts, la cible evidente est Windows, pas Linux

          Quand a Google qui paye la MoFo, je vois ca surtout comme un moyen supplementaire de pousser leurs services tout simplement, c'est le 2eme browser en termes de parts de marche, c'est pas rien.
        • [^] # Re: Linux parent pauvre du fait de part de marché

          Posté par (page perso) . Évalué à 4.

          >il ne faut pas oublier que le bailleur de fonds de la mozfo c'est google

          Google n'est pas le bailleur de fond. Il n'y a qu'un simple contrat entre la MoCo et Google : argent en echange de trafic. point barre.

          Mozilla peut très bien survivre sans google. Si là, maintenant, tout de suite, le contrat était rompu, Mozilla a de quoi survivre pendant 3 ans avec les mêmes dépenses. D'ailleurs, il est possible que Mozilla puisse être auto-financé avec des réductions de dépenses.
      • [^] # On mesure quoi exatement?

        Posté par (page perso) . Évalué à 1.

        Il existe une différence de performances soit mais rien ne dit qu'elles sont dues uniquement au navigateur sans remettre en question le sytème d'exploitation (pas tapper).
        On peut imaginer des raisons complexes qui tiennent tant à l'OS qu'à l'implémentation.
        Bref c'est une question qui ne peut être traîtée que sous l'angle de l'application.
        • [^] # Re: On mesure quoi exatement?

          Posté par (page perso) . Évalué à 6.

          Sauf que Chromium va très vite sur les 2 OS.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Linux parent pauvre du fait de part de marché

        Posté par (page perso) . Évalué à 4.

        il n'y a pas de "branches" linux.

        Les versions Linux et Windows partagent au moins 90% du code, et sont dans la même branche. Les seuls grosses différences, ce sont les couches basses, donc les accès au reste de l'OS (système graphique, système de fichiers etc..)

        Le moteur JS, le moteur de rendu etc, tout est absolument identique.
  • # ?

    Posté par . Évalué à 3.

    >Comment fait donc l'auteur pour faire de ses binaires des Firefox de course
    /*blague*/il compile avec ICC, et obtiens un binaire troué mais super rapide /*blague*/
    je->

    As tu essayer Fennec ? Le Firefox de Moblin, en plus d'être ergonomique, joli et pratique, il est rapide. Moins que Chromium ou Midori ou Arora. Mais c'est clair que Chromium met un sacré coup de vieux aux autres.
  • # 32 vs 64 bits

    Posté par . Évalué à 5.

    Ton firefox sous linux était-il en 64 bits ? Si oui, tu n'as donc pas tracemonkey, qui n'est dispo qu'en 32 bits...
    Ça explique la différence de perf ?
    • [^] # Re: 32 vs 64 bits

      Posté par . Évalué à 2.

      Hier justement je suis passé sur firefox 3.7a1pre, je savais même pas que tracemonkey était désactivé en 64 bits, je l'ai appris hier soir...

      J'avais fait un bench sunspider sur firefox 3.5 sans tracemonkey, en total 2800ms environ.
      Sur firefox 3.7a1pre je suis à 1347ms. Avec chromium ça tombe à 650ms...

      Malheureusement, même si j'aurai bien envie d'utiliser chromium que je trouve plus réactif de manière générale, le manque de fonctionnalités se fait sentir quand même (pas de filtrages des cookies, pas de noscript, un adblocker pas super efficace..).
      • [^] # Re: 32 vs 64 bits

        Posté par . Évalué à 3.

        +1 pour les adblocker: les pubs google en particulier continuent pas être visible (chrome/chromium + adsweep/adblock).

        Serait-ce un complot ?
    • [^] # Re: 32 vs 64 bits

      Posté par . Évalué à 3.

      64 bits en effet, mais [1] semble mentionner que Tracemonkey est disponible sur x86_64 depuis quelques mois. D'ailleurs, le flag javascript.options.jit.content est bien sur true. Donc a priori j'utilise Tracemonkey, non ?

      [1] http://groups.google.com/group/mozilla.dev.tech.js-engine/br(...)
      • [^] # Re: 32 vs 64 bits

        Posté par . Évalué à 3.

        Effectivement, d'après les perfs d'un firefox 32 bits sur ma machine, ça doit venir de tracemonkey qui est désactivé en 64 bits :(
  • # avec le navigateur kazehakase

    Posté par (page perso) . Évalué à 3.

    Peacekeeper 1163 points

    If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

    • [^] # Re: avec le navigateur kazehakase

      Posté par (page perso) . Évalué à 3.

      et sunspider

      RESULTS (means and 95% confidence intervals)
      --------------------------------------------
      Total: 2198.0ms +/- 5.8%

      If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

  • # Firefox vs le reste du monde

    Posté par . Évalué à 10.

    À ce jour, Firefox n'est peut-être pas le plus rapide des navigateurs, mais il est tellement pratique avec ses extensions que ça m'importe peu. Comparons ce qui est comparable : je suis curieux de voir ce que deviendra la vitesse des autres navigateurs quand ils proposeront une infrastructure permettant des extensions qui ont accès à chaque requête & réponse HTTP qu'effectue le navigateur afin d'effectuer du filtrage/analyse/modificiation de contenu à la volée ...

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # [Addendum] Firefox vs le reste du monde

      Posté par . Évalué à 6.

      ( Cela dit, je n'exclus pas qu'une partie de sa "faiblesse" puisse être du à une architecture et/ou du code hérité d'un passé difficile )

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Firefox vs le reste du monde

      Posté par . Évalué à 4.

      Je partage tout à fait ton analyse, mon journal n'était là que pour commenter la rapidité des uns et des autres, et ma surprise quand à la différence linux/windows, qui s'avère être une surprise 32bits/64bits (Tracemonkey), cf. plus bas.
    • [^] # Re: Firefox vs le reste du monde

      Posté par . Évalué à 2.

      Chrome vient de mettre son système d'extension en place.
      J'ai peur que ça puisse ressemble a un coup de massu pour firefox principalement sauvé pour ses extensions, si évidement ça fonctionne.
      • [^] # Re: Firefox vs le reste du monde

        Posté par . Évalué à 5.

        Ça marche à peu près. On y trouve des équivalents à adblock plus et à flashblock, mais rien encore de très évolué. Cela dit c'est effectivement récent. Pour moi, le principal problème est celui de la vie privée car il n'y a pas de filtrage du contenu possible a priori (c'est à dire que les pubs, par exemple, sont téléchargées mais pas affichées), voir

        https://linuxfr.org//comments/1089078,1.html

        D'autre part, deux sites qui montrent que les extensions sous Chrome/Chromium arrivent, et que ce n'est pas de la gnognotte, même si on est encore très loin de Firefox. Très loin, pour combien de temps ?

        http://www.chromeextensions.org/
        https://chrome.google.com/extensions
        • [^] # Re: Firefox vs le reste du monde

          Posté par (page perso) . Évalué à 2.

          Dans ce cas, il reste la solution privoxy. Simple, et très efficace.

          Envoyé depuis mon lapin.

          • [^] # Re: Firefox vs le reste du monde

            Posté par . Évalué à 3.

            Privoxy ne filtre qu'avec des expression régulières et non en utilisant l'arbre DOM, ce qui le rend assez peu efficace. Les règles sont difficiles à écrire pour éliminer du contenu publicitaire en HTML, et sont ensuite très lentes à l'exécution.
            • [^] # Re: Firefox vs le reste du monde

              Posté par (page perso) . Évalué à 2.

              Que les règles soient plus difficiles, je suis d'accord, les expressions régulières, c'est de l'art. Par contre, je ne suis pas certain que ce soit plus lent, un arbre dom, c'est quand même très lourd à mettre en place.

              Envoyé depuis mon lapin.

              • [^] # Re: Firefox vs le reste du monde

                Posté par . Évalué à 4.

                Les regexp c'est surtout ingrat et fastidieux. L'expérience montre que ce genre de solution est à éviter quand il existe des méthodes alternatives et des outils faits pour traiter les structures de données à adresser comme c'est le cas dans cet exemple. Surtout qu'il faut en plus régulièrement remettre à jour la base de règles de filtrage. Bref belle perte de temps surtout quand on n'a pas que ça à faire.
                Niveau performances j'ai essayé un temps de remplacer adblock par privoxy, la différence de performances est flagrante (sans parler de la flexibilité).
                • [^] # Re: Firefox vs le reste du monde

                  Posté par (page perso) . Évalué à 0.

                  Question de goûts, j'aime bien écrire des regexp.

                  Mais c'est vrai que privoxy donne une impression de lenteur, mais ça n'a peut-être rien à voir avec les regexp. Puis il n'est pas impossible de faire un proxy qui construit un arbre dom.

                  Envoyé depuis mon lapin.

              • [^] # Re: Firefox vs le reste du monde

                Posté par . Évalué à 5.

                > Par contre, je ne suis pas certain que ce soit plus lent, un arbre dom, c'est quand même très lourd à mettre en place
                D’où l’intérêt de mettre en place le filtrage dans le navigateur, puisque ce dernier devra de toute manière construire l’arbre DOM.
                Indépendamment de ça, il faut voir que gérer l’imbrication avec des expressions régulières, c’est presque mission impossible. Supprimer [div id="pub"]...[div]...[/div]...[/div] sans casser l’arbre, c’est sioux avec une expression régulière.
                (et libxml2 a des performances tout à fait honorables)
      • [^] # Re: Firefox vs le reste du monde

        Posté par . Évalué à 1.

        Reste l'intégration. Firefox s'en sort relativement bien, tout du moins de ce que je peux voir sous Gnome (thème, trousseau, fenêtres enregistrer/ouvrir/imprimer/etc, positionnement des menus et icônes) et du peu que j'ai pu le tester sur d'autres systèmes.
  • # Dans le détail

    Posté par . Évalué à 8.

    Est ce que quelqu'un à 1800 euros pour que je fasse le même test sur mac os X ? C'est uniquement pour la science.

    Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

    • [^] # Re: Dans le détail

      Posté par . Évalué à 5.

      Fait hier: safari 4.0.4 poutre tout le monde, même Chrome/Chromium.
    • [^] # Re: Dans le détail

      Posté par (page perso) . Évalué à 2.

      Ma copine à un Macbook avec un dual core 1,83 Ghz, moi un amd 64 3000+

      Firefox est beaucoup plus rapide sur archlinux que sur Mac OS X. Pourtant mon PC et bien moins puissant et j'ai 2 fois moins de RAM qu'elle. Pour le reste il est clair que Safari est très très rapide.
      • [^] # Re: Dans le détail

        Posté par . Évalué à 3.

        simplement parce qu'il faut utiliser camino sous mac OS et pas firefox ;)
  • # Buildconfig ?

    Posté par (page perso) . Évalué à 3.

    À titre de comparaison sur un Firefox 3.6b4 x86_64 (AMD Turion 64 X2 @ 1,8 Ghz) ça me donne :

    Sunspider : 2499.0ms +/- 8.0%
    Peacekeeper : 1458 points

    et pour rigoler j'ai regardé Sunspider sous Konqueror (4.4 beta 1), eh bah c'est pas glorieux, KJS est pas très en forme, mais ça reste un navigateur plus que correct.

    Sunspider : 8733.6ms +/- 3.5%
    Peacekeeper : pas arrivé jusqu'au bout …

    Donc effectivement le build de ta distribution n'est pas optimisé puisque mon simple Turion de PC portable bat quasiment ton QuadCore sur SunSpider et le bat sur Peacekeeper, alors que je n'étais pas vraiment au repos (y'a d'autres choses qui tournaient en arrière plan).

    Pour savoir un peu ce qui pourrait changer, tu pourrais donner ce que Firefox t'affiche en mettant about:buildconfig dans la barre d'adresse, actuellement ça donne ça chez moi :


    about:buildconfig

    Build platform
    target
    x86_64-unknown-linux-gnu

    Build tools
    Compiler Version Compiler flags
    gcc gcc version 4.4.2 (GCC) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -march=native -O2 -pipe -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-use -Os -freorder-blocks -fno-reorder-functions
    c++ gcc version 4.4.2 (GCC) -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -march=native -O2 -pipe -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -fprofile-use -Os -freorder-blocks -fno-reorder-functions

    Configure arguments
    --enable-application=browser --prefix=/usr --libdir=/usr/lib --with-system-nss --with-system-jpeg --with-pthreads --with-system-zlib --with-system-bz2 --with-system-png --enable-system-cairo --with-system-hunspell --with-system-sqlite --with-system-nspr --disable-installer --disable-updater --enable-official-branding --enable-startup-notification --disable-pedantic --enable-jemalloc --enable-xterm-updates --enable-optimize --disable-debug --disable-tests --enable-profile-guided-optimization --enable-strip --enable-install-strip --disable-crashreporter --disable-parental-controls --enable-printing --enable-xinerama --enable-default-toolkit=cairo-gtk2 --enable-places --enable-svg --enable-pango --enable-canvas --enable-smil --disable-java-xpcom --disable-canvas3d --disable-safe-browsing


    À comparer donc de votre coté, y'a sûrement pas mal de choses qui peuvent jouer, et surtout c'est à comparer avec la version Windows (que je n'ai pas sous la main).
    • [^] # Mandriva x86-64, Firefox 3.5 => ouch

      Posté par . Évalué à 2.

      Ouille, Firefox 3.5 (build Mandriva x86-64) est très lent sur mon Athlon X2 3600+ :

      SunSpider : 18120.4ms
      Peacekeeper : 824 points


      about:buildconfig donne :

      gcc gcc version 4.4.1 (GCC) -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions
      c++ gcc version 4.4.1 (GCC) -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions

      --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib64 --includedir=/usr/include --datadir=/usr/share --sysconfdir=/etc --enable-application=xulrunner --with-pthreads --with-system-jpeg --with-system-zlib --with-system-bz2 --with-system-png --with-system-nspr --with-system-nss --enable-system-sqlite --enable-system-cairo --enable-system-hunspell --disable-ctl --enable-javaxpcom --enable-pango --enable-svg --enable-canvas --enable-crypto --disable-crashreporter --enable-extensions --disable-installer --disable-updater --enable-optimize --enable-jemalloc --disable-wrap-malloc --enable-valgrind --disable-strip --enable-startup-notification --enable-default-toolkit=cairo-gtk2 --with-java-include-path=/usr/lib/jvm/java-rpmbuild/include --with-java-bin-path=/usr/lib/jvm/java-rpmbuild/bin --enable-image-encoder=all --enable-image-decoders=all --enable-extensions=default,python/xpcom --enable-places --enable-storage --enable-safe-browsing --enable-url-classifier --disable-tests --disable-mochitest --with-distribution-id=com.mandriva
      • [^] # Re: Mandriva x86-64, Firefox 3.5 => ouch

        Posté par . Évalué à 2.

        Mon quad core est guéri par Minefield/3.7a1pre : 916.0ms +/- 4.8%

        Il y a du progrès, même s'il reste un facteur 2 avec Chrome/Chromium.
      • [^] # Re: Mandriva x86-64, Firefox 3.5 => ouch

        Posté par . Évalué à 3.

        Epiphany 2.28.1 : 820.4ms sous SunSpider... (20x plus rapide que FF)
      • [^] # Re: Mandriva x86-64, Firefox 3.5 => ouch

        Posté par . Évalué à 2.

        Comme j'ai dit dans un précédent commentaire, ils utilisent "-fexceptions" par défaut chez Mandriva. Cela dit, ce n’est pas forcement significatif.

        Pour du x86-64, sans faire de profile feedback, tu peux déjà rajouter les options suivantes : tintin j'ai perdu les options exactes (j'ai passé 2 jours à recompiler gcc 4.4, avec le support de la branche graphite et pour comprendre l'Integrated Register Allocator, + 1 jour pour savoir comment les activer pour recompiler Firefox ... je crois que j'ai fini par faire des alias pour ajouter les bonnes options (le truc douteux)). Bon courage, mais je me suis lourdement inspiré du magistral journal de sir patrick_g ( http://linuxfr.org/2009/04/21/24809.html ).

        Bref, on obtient des gains, et c'est rassurant, sans toucher aux options de link (sauf si tu fais du profile feedback), et en ne se focalisant que sur les options apportées par gcc4.4 (c'est à dire, sans chercher à optimiser vraiment, en étudiant toutes les possibilités des précédentes versions de gcc, en laissant les exceptions par exemple).
    • [^] # Re: Buildconfig ?

      Posté par . Évalué à 2.

      Toujours à titre de comparaison, j'ai testé plusieurs navigateurs sur mon netbook qui tourne lui-même sous Ubuntu karmic :

      * Sunspider :

      * firefox 3.5.5 : 5870.8ms
      * firefox nigthly build 3.7a1pre : 3670.2ms
      * Chromium 4.0.267.0 : 2251.6ms
      * Midori 0.1.9-0 : 2325.2ms
      * Epiphany 2.28.0 : 2382.2ms

      * PeaceKeeper :

      * firefox 3.5.5 : 430
      * firefox nigthly build 3.7a1pre : 560
      * Chromium 4.0.267.0 : planté
      * Midori 0.1.9-0 : planté
      * Epiphany 2.28.0 : planté

      Firefox s'améliore mais le gagnant sous Sunspider est Chromium grâce à Google V8. Les autres browsers qui tournent avec webkit restent semblable à Chromium.

      Sinon j'ai pas de Windows pour comparer...
      • [^] # Re: Buildconfig ?

        Posté par . Évalué à 2.

        Ouch de nouveau. Sur mon netbook Mandriva à base d'Atom, Firefox 3.5 renvoie 32396.4ms sous SunSpider...
  • # uzbl et surf

    Posté par . Évalué à 2.

    uzbl et surf sont deux navigateur très simple et très rapide ça donne quoi avec ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: uzbl et surf

      Posté par (page perso) . Évalué à 0.

      Avec uzbl (git.20091130, webkit 1.1.17), j'ai 581.0ms à sunspider.
      • [^] # Re: uzbl et surf

        Posté par . Évalué à 2.

        559.8ms a sunspider sur la même machine que les tests du journal.
        • [^] # Re: uzbl et surf

          Posté par . Évalué à 3.

          Donc mieux que firefox mais légèrement moins bien que chrome/chromium. Merci :)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Utilisation du cpu ou de quoi alors?

    Posté par . Évalué à 1.

    Salut et merci pour ces tests

    je me demandais qu'est ce qui ralentissait firefox...
    toi, sous firefox , tu as 2549 à SunSpider avec le core 2 quad

    moi, sous iceweasel 3.5.5 + debian sid + xfce, j'ai 3100 souvent (et une fois 2700 (?) )avec un athlon xp barton 2500+ (1,83 ghz), un truc de 2003-2004
    et le cpu est à peu près à 20-30% pdt le test (contre 3% là qd je tapes)

    donc, la question à 10 balles, qu'est ce qui ralentit firefox?
    le DD ne gratte pas, ya de la ram... voila quoi :D
  • # et les autres

    Posté par . Évalué à 4.

    Pourquoi n'avoir pas testé les autres navigateurs principaux sous linux :

    epiphany (en version gecko puis webkit)
    konqueror

    et éventuellement midori ou arora...
    • [^] # Re: et les autres

      Posté par . Évalué à 3.

      Pourquoi ? Parce que j'ai testé ceux qui m'interessent en priorité :)

      Konqueror 4.3.4, c'est 2774ms sous sunspider, et avec 1729 peacekeeper, soit plus ou moins la même chose que Firefox sans Tracemonkey.
      • [^] # Re: et les autres

        Posté par . Évalué à 5.

        Ce qui me gêne c'est que le titre de ton journal entend que tu fais une conclusion un peu vite, alors que les tests effectués un peu plus haut dans les réponses montrent que midori ou epiphany semblent être au niveau de chromium question perfs sous linux. Donc il me semble que globalement, les navigateurs sous linux ne sont pas spécialement plus lents que sur les autres os et qu'il n'y aurait que firefox sous linux qui ait un réel problème de lenteur.

        Bon et puis après, c'est quoi cette sombre histoire de vitesse ? tu meurs si le site se charge 1ms plus tard ? J'ai testé chrome une fois. OK certaines pages semblaient effectivement se charger plus vite. Mais au final passé ce ressenti, ça ne me faisait pas lire les textes ni les images plus vites. Tu y gagnes quoi avec un browser plus rapide, tu as une trique plus bestiale quand tu t'astiques sur youporn avec chrome ou firefox sous windows ?

        Moi franchement les seuls problèmes de lenteurs qui peuvent me déranger sous linux, c'est quand je vais sur un site avec un navigateur équipé du plugin flash proprio et que la moindre petite pub en flash fait monter inutilement le cpu de mon netbook (et vide sa batterie par la même occasion)...
        • [^] # Re: et les autres

          Posté par . Évalué à 6.

          1. le titre de mon journal a été choisi sur la base des données qu'il présente, ne me fais pas le procès de ne pas avoir tenu compte d'informations que j'ai eues ensuites :)

          2. Firefox n'a pas de problème sous linux, c'est la version 64 bits de firefox qui pose problème car Tracemonkey y est désactivé. Les performances de la version 32 bits sont ok.

          3. la vitesse ne fait peut-etre pas la différence pour toi, mais comme je le disais, dans les années qui viennent, avec 1/ les sites "lourds" qui sont amenés à se développer, 2/ la vitesse des connexions ADSL qui augmentent, et 3/ la recherche d'une meilleure utilisation énergétique, la pression sur l'efficacité du code va aller en augmentant.

          Alors évidemment, un navigateur rapide ne fait pas lire plus vite. Mais si le grand public peut, plus rapidement, ouvrir un mail de gmail, déplacer un rdv dans google calendar, ou encore surfer la wave qu'il souhaite, tout en économisant de sa batterie et sans être ralenti par les autres onglets ouverts, je crois que ça va être difficile de choisir autre chose que Chrome/Chromium - a features équivalentes. Or, la vitesse est une feature comme une autre. Dans ce domaine Chrome/Chromium font la loi en dehors du monde Apple, tout en progressant efficacement dans les autres directions (extensions, etc.). J'attends avec une grande impatience les progrès de Firefox, et d'après ce que je vois de la 3.7a, ça poutre, et je m'en réjouis.

          Concernant flash: pareil que toi sur le flash. Ça me gonfle. Mais c'est là.
          • [^] # Re: et les autres

            Posté par . Évalué à 6.

            Concernant flash: pareil que toi sur le flash. Ça me gonfle. Mais c'est là.
            Saleté de plugin fourbe qui s'installe tout seul! Ou alors ton admin est méchant?

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

            • [^] # Re: et les autres

              Posté par (page perso) . Évalué à 3.

              Peut-être qu’il a installé une Mandriva One, ce cheval de Troie du grand capital marchand et privateur de libertés…
  • # Et maintenant

    Posté par (page perso) . Évalué à 2.

    La question est qu’est-ce-que le statu opensource de firefox nous permet de faire pour essayer d’améliorer la situation ?
    On écrit une lettre à Tritan Nitot ?
    On essaye de faire en sortes que les distos fournissent des paquets plus optimisés ?
    Est-ce plus « profond » comme problème ?
    • [^] # Re: Et maintenant

      Posté par . Évalué à 3.

      Cf. commentaires + hauts : le problème vient de TraceMonkey, qui est désactivé lorsque Firefox est compilé en 64 bits. Avec Firefox Minefield 3.7a, le speedup est tonitruant : 900ms et des soupières au benchmark Sun Spider :)
    • [^] # Re: Et maintenant

      Posté par . Évalué à 6.

      "La question est qu’est-ce-que le statu opensource de firefox nous permet de faire pour essayer d’améliorer la situation ?
      On écrit une lettre à Tritan Nitot ?
      On essaye de faire en sortes que les distos fournissent des paquets plus optimisés ?
      Est-ce plus « profond » comme problème ? "

      La première chose à faire serait que les utilisateurs de Linux fassent du beta testing des versions à venir...

      Ont dit souvent que les linuxiens sont de bons bêta-testeurs, c'est peut-être vrai, mais ce qui est sûr c'est qu'ils sont extrêmement rares ! Il ne m'est jamais arrivé de rapporter un bug de la version Linux de Firefox qui soit marqué comme "duplicate" alors que sous Windows c'est quasi systématique que quelqu'un l'ait déjà rapporté (plusieurs fois en général).

      La version 3.6 sort normalement le mois prochain et il n'y a presqu'aucun bêta testeurs sous Linux (même pas 1% des bêta testeurs de la 3.6 sont sous Linux...). On a une petite élite sous Linux qui n'hésite pas à utiliser les versions de test, fait des patchs et rapporte des bugs (au passage un grand bravo à TGL dans ce thread pour avoir proposé un patch!!!) et l'immense majorité (pour ne pas dire pratiquement tout le monde) des utilisateurs a une peur bleue de tester des versions de développement. C'est à mon sens une raison majeure de la différence de qualité entre la version Linux et la version windows, si on pouvait ne serait-ce que multiplier par 10 le nombre de beta testeurs des versions bêta, voire, soyons fous, des compils nocturnes...


      • [^] # Re: Et maintenant

        Posté par . Évalué à 2.

        Ben moi je l'utilise, ça marche, je me plains pas...
        C'est pas bien ?

        Y'a peut être trop de linuxiens qui se foutent des perfs par rapport aux autres navigateurs ? On est peut être pas assez obsédés par ça ...
        • [^] # Re: Et maintenant

          Posté par . Évalué à 4.

          Personne n'est forcé de contribuer au libre, je trouve juste un peu dommage que les linuxiens se reposent sur le bêta testing fait par les windowsiens et les macqueux plutôt que de participer au projet Mozilla plus activement.
          • [^] # Re: Et maintenant

            Posté par . Évalué à 1.

            Tu réponds pas à ma question : peut être que les linuxiens n'ont pas les même préoccupations que les windowsiens. Peut être qu'on ne joue pas autant à kikalaplugrosse, surtout pour des VM JavaScript... Puis y'a peut être trop de linuxiens en 64 bits, que vous avez pendant longtemps ignoré.

            Enfin, comme il faut que ça soit en paquet pour qu'on l'installe sans être pris d'une crise de conscience... on peut pas tester les nightly :) (mauvais argument je trouve, une nightly ça se décompresse bien dans un ~/bin)
            • [^] # Re: Et maintenant

              Posté par . Évalué à 1.

              sauf que pas de bêta testeurs = de moins bonne perfs mais surtout une appli plus boguée que pour sa version Windows.
              • [^] # Re: Et maintenant

                Posté par . Évalué à 2.

                En même temps je vois pas de bugs particuliers, à part le problème de performances dont ils parlent...
          • [^] # Re: Et maintenant

            Posté par . Évalué à 2.

            Je ne connais pas les parts de marché de Firefox par OS mais
            si tu as seulement 10% des utilisateurs FF sous Linux et que la même proportion des utilisateurs d'un OS remonte des anos, il est normal qu'il n'y ait qu'une faible proportion de bugs remontés par des linuxiens, non ?
            • [^] # Re: Et maintenant

              Posté par . Évalué à 2.

              Il y a 2,17% des utilisateurs de Firefox sous Linux et il n'y a que 0,78% des utilisateurs de 3.6 sous Linux, 3 fois moins donc, ce qui n'est pas le cas de Mac et Windows. 99,2% des bêta testeurs sont donc sous Mac ou Windows.

              Pire, les deux tiers des utilisateurs Linux sont sous Firefox 2.0 et 3.0, des versions obsolètes ou proches de l'être (fin de support probable dans un mois pour la branche 3.0).
          • [^] # Re: Et maintenant

            Posté par . Évalué à 2.

            Un problème avec Mozilla c'est que les builds officiels ne sont pas intégrés au bureau, que ce soient les icones, le rendu des fontes (atroce), etc. Du coup on peut bien tester 5 minutes pour voir, mais on retourne vite fait au client fourni par la distro.
            • [^] # Re: Et maintenant

              Posté par . Évalué à 3.

              J'utilise les builds officiels depuis toujours et je n'ai pas de problème de rendu de police, j'en ai eu il y a longtemps sur Hardy (librairie Cairo trop vieille) mais depuis un an c'est bon.

              Pour l'icône, bah j'utilise une icône Firefox (dossier icons dans le tar.gz).
      • [^] # Re: Et maintenant

        Posté par (page perso) . Évalué à 1.

        Alors moi j’utilise la version 3.6 en nightly depuis longtemps (avec le dépôt ubuntu quivabien j’ai des mises à jour quasi quotidiennes) parceque je suis curieux.
        Je ne rapporte pas de bugs… parce que je n’en vois pas ! Concernant ces problèmes de perfs, je n’avais jamais fait le test, on me dit que la 3.6 est plus rapide, j’essaie sans pouvoir aller beaucoup plus loin car comme je ne suis pas capable d’écrire la moindre ligne de code, donc le moindre patch, ma contribution s’arrête là !
        J’ai installé l’extension « test pilot » pour pouvoir aider comme je peux. Mais sur ces questions de vitesse, je ne vois pas en quoi plus de bêta testeurs changerait quoi que ce soit.
        • [^] # Re: Et maintenant

          Posté par . Évalué à 1.

          Tout d'abord, merci de contribuer et de tester 3.6! :)

          Quand tu as un grand nombre de bêta testeurs, ça veut dire que tu as un grand nombre de configurations matérielles et logicielles. Là tout va bien dans ton cas, mais un utilisateur sous une autre configuration pourrait lors de la mise à jour d'une nightly se rendre compte par exemple que le scrolling est devenu plus lent et rapporter ce bug, ou bien que telle application web rame alors qu'avant ce n'était pas le cas. Il peut arriver qu'un bug de perf n'apparaisse qu'avec une version d'une librairie spécifique, Cairo par exemple qui est très utilisée par Firefox, ou bien avec une extension spécifique, Firebug par exemple.

          La régression peut aussi ne pas être liée au perf et c'est encore plus utile de les rapporter, par exemple récemment en mettant à jour ma nightly en 3.7 je me suis rendu compte que les polices des menus étaient devenues plus grandes que celles de mon système, c'était dû à un patch améliorant le support de Linux Maemo pour le mobile et ça n'étais visible que si ton système avait les polices réglées en dessous de 96dpi, ce qui était mon cas.
      • [^] # Re: Et maintenant

        Posté par (page perso) . Évalué à 1.

        Elle est bien bonne, celle-là, c’est la faute des Linuxiens, maintenant… Et elles sont où les builds officielles 64 bits, hein ? Tout mon système est 64 bits, je n’installe que du 64-bits, on dirait que la MoFo est encore à la préhistoire de l’informatique, sur ce coup-là. Même Opera fournit des builds officielles 64 bits depuis des mois !

        Et puis aussi, si les Linuxiens cessaient de croire les éditeurs de distro qui leurs serinent à longueur de forum « n’installez rien en dehors des dépôts officiels et des RPM (ou deb) de vos dépôts, sinon, c’est la fin du monde et vous allez faire pleurer le petit Jésus », ça irait peut-être mieux.
        Tu dis que les Linuxiens ont une peur bleue d’installer des logiciels instables : c’est pas tout à fait exact. Ils ont surtout peur de sortir des sentiers battus de leur distro. Ça irait peut-être mieux si la MoFo fournissait des paquets pour les principales distro (comme Opera, une fois de plus…)
        • [^] # Re: Et maintenant

          Posté par . Évalué à 4.

          La question n'est pas ce que Mozilla peut faire pour Linux, mais ce que tu peux faire pour Mozilla. Tu as une réaction de pur consommateur, c'est des bêta testeurs qu'on cherche pour améliorer la qualité de la version Linux. Si tu t'intéressais un minimum à Mozilla tu saurais qu'on a des builds 64bits sur le FTP qui n'attendent qu'à être utilisées et testées.
          • [^] # Re: Et maintenant

            Posté par (page perso) . Évalué à 0.

            OK, je viens de m’y interesser à nouveau, j’ai trouvé — pas du tout à l’endroit du FTP où je cherchais, mais bon… C’est une version US, j’ai pris le chrome de la version 32bit FR, et je l’ai copié dans à la place du chrome 64bit US, j’espère que ça va pas trop tout casser ! Bon, voilà, je teste, alors… :-)
          • [^] # Re: Et maintenant

            Posté par . Évalué à 1.

            La question n'est pas ce que Mozilla peut faire pour Linux, mais ce que tu peux faire pour Mozilla.
            Non. la question est ... ah ben y'a pas de question. Y'a pas de raison particulière qui fait que l'utilisateur de base ait à se prendre la tête a installer mofo parce que "vous comprenez il faut qu'il en chie... euh non parce que c'est pas a mofo de faire des efforts".

            La mofo a bien un installateur pour windows et ne demande pas aux user de le compiler non ?

            Bref : Mozilla n'est pas "au service" de l'utilisateur (c'est un ll, you want it you code it, toussa), mais inversement, l'utilisateur n'est pas au service de la mofo, et si la mofo ne veut pas s'adapter aux utilisateurs, elle aura moins de beta testeurs, c'est aussi simple que ça
            • [^] # Re: Et maintenant

              Posté par . Évalué à 4.

              Apparemment ta conception du libre c'est que c'est les autres qui font le boulot et toi tu en profites tout en crachant à la gueule de ceux qui bossent. Belle mentalité.

              Pour ceux qui auraient lu les âneries de ce gars, il n'est évidemment pas question de compiler Firefox, on fournit des binaires tous les jours qui se lance d'un double clic et c'est pas des utilisateurs de base que l'on cherche mais des bêta-testeurs, donc des personnes ayant quelques compétences techniques, pas Mme Michu.

              Ceci dit quand je dis qu'on cherche, *je* cherche, parce que je suis un Linuxien et que je trouve dommage qu'on ait si peu de feedback sur cette plateforme, pour Windows et Mac on a un million de bêta testeurs actuellement donc pas besoin de bras de ce côté.
              • [^] # Re: Et maintenant

                Posté par . Évalué à 2.

                si tu savais lire tu aurais remarqué quelques petites choses :
                je t'aide
                Mozilla n'est pas "au service" de l'utilisateur (c'est un ll, you want it you code it, toussa),
                vas y, ressaie de lire à partir de ça tu verras, tu comprendras plein de truc (quand on lis, on comprend mieux souvent).

                Apparemment ta conception du libre c'est que c'est les autres qui font le boulot et toi tu en profites tout en crachant à la gueule de ceux qui bossent. Belle mentalité.
                Comme tu le dis si justement : visiblement ta conception de la discussion c'est tu lis pas, tu comprend pas, mais tu attaques.
                Belle mentalité.

                et c'est pas des utilisateurs de base que l'on cherche mais des bêta-testeurs, donc des personnes ayant quelques compétences techniques, pas Mme Michu.
                Ah merde j'aurais bien répondu, mais comme c'est pas la première ligne, tu ne liras sans doute jamais ça :
                Et il t'es jamais venu a ton esprit que je parlais des paquets (deb, rpm, toussa) ? Que certains n'ont aucune envie de gerer des softs en plus de leurs arbres de packages parce qu'ensuite c'est une merde pas possible a tracer et a mettre a jour ?
                • [^] # Re: Et maintenant

                  Posté par . Évalué à 3.

                  Tu cherches visiblement la bagarre. Personnellement, j'ai mieux à faire de mon temps que d'interagir avec des personnes négatives et polémiques par nature, contribuer au libre par exemple. Bonne nuit.
                  • [^] # Re: Et maintenant

                    Posté par . Évalué à 0.

                    Tu cherches visiblement la bagarre.
                    Clair que c'est moi qui commence a faire des attaques perso sans lire les commentaires.

                    Personnellement, j'ai mieux à faire de mon temps que d'interagir avec des personnes négatives et polémiques par nature
                    Tu fais comment pour ne pas interagir avec toi même ?
                    (oui c'est du bassement personnel, mais des fois y'a un minimum d'humilité a avoir, surtout quand on est la personne qui commence a expliquer que
                    1°) ce sont aux utilisateurs de bosser, pas à la mofo
                    2°) si on ose répondre, alors je lis pas mais je dis que tu as une mentalité de merde en t'accusant de n'importe quoi
                    3°) si on ose a nouveau répondre, c'est que je n'ai rien fait, que je suis blanc comme neige, mais que c'est l'autre qui est "négatif et polémique" ".
                    mais c'est moi qui suis "négatif et polémique" ...
                    )
        • [^] # Re: Et maintenant

          Posté par . Évalué à 1.

          Tout mon système est 64 bits, je n’installe que du 64-bits, on dirait que la MoFo est encore à la préhistoire de l’informatique, sur ce coup-là.

          Les processeurs x64 peuvent executer du code 32bits de facon transparente, Tout OS 64bits digne de ce nom est capable d'executer des binaires 32bits, je pense que tu devrais changer de distrib...

          Par ailleurs, a part les fanboys et ignares, la plupart des gens soit s'en foutent, soit savent qu'une majorite des applis ne beneficie d'aucune amelioration avec le passage en 64bits. Au contraire, parfois tu perds des perfs avec une occupation memoire plus importante (taille de cache, tout ca...).

          Apres si tu peux me pointer les raisons techniques concertant Firefox qui te poussent a vouloir un build 64bits (des benchmarks sur une amelioration significative des perfs globales en 64bits, ce genre de chose, avec analyse technique STP), ca serait interessant.
          • [^] # Re: Et maintenant

            Posté par . Évalué à 3.

            Les processeurs x64 peuvent executer du code 32bits de facon transparente, Tout OS 64bits digne de ce nom est capable d'executer des binaires 32bits, je pense que tu devrais changer de distrib...
            Le problème n'est pas executer "un binaire" c'est avoir toutes les libs 32 bits en plus des 64 bits qu'un soft utilise! Parce qu'un soft 32 bits est incapable d'utiliser des libs 64 bits.
            ET certains (comme moi) n'ont pas envie de mettre une palanquée de libs qui ne servent que pour un soft qui a décidé de ne pas suivre l'évolution informatique de ces 5 dernières années (mais qui bien souvent a confortablement suivi l'évolution du marché de la mémoire).
            • [^] # Re: Et maintenant

              Posté par . Évalué à 1.

              Ok, pas de probleme, tu veux pas prendre de la place sur ton disque pour les libs 32bits. Vu la capacite des disques aujourd'hui ca va cependant etre assez difficile a defendre comme choix technique (a la rigueur sur du Notebook, mais bon du notebook 64bits avec un disque minuscule, ca va etre de plus en plus difficile a trouver...).

              Linux: 1% du marche desktop
              Utilisateurs linux 64bits sans les libs 32bits: hum, pas beaucoup?
              Utilisateurs linux 64bits sans les libs 32bits sur un Netbook avec un petit disque dur: 1 pingouin dans sa cave?
              • [^] # Re: Et maintenant

                Posté par . Évalué à 2.

                pas un problème de "place" , un problème de gerer deux versions des mêmes trucs en parallèles, de savoir si lorsque tu installe l'une, est ce que tu installe l'autre, et ainsi de suite.
                Qu'est ce que je fais si j'ai une maj de l'une et pas de l'autre, si j'en ai une et pas l'autre, ...


                Si toi ca t'amuse quant tu installe un serveur ou une machine burautique c'est "je fous tout le repository j'ai de l'espace" , chez moi (bureautuque ou serveur) c'est partoch séparé, et on défini la taille des partoch à l'install (même si on utilise lvm) suivant la destination de la machine.
                Et puis c'est aussi "j'installe ce dont j'ai besoin, pas plus, pas moins".

                Ca c'est un choix technique.

                Le choix du "j'installe tout et n'importe quoi en n versions différentes" ... euh je trouve pas de raisons techniques valables.
                Au cas par cas à l'extrême rigueur, mais non je vois pas de raison technique valable.

                Et le coup du "je peux donc je le fait" comment dire... je peux donner le compte root à tout le monde, pas pour autant que je le fait.

                Enfin tu dis "ouais on a plein de place" :
                j'ai ma partoche système qui est occupé à 85% (grosse pourtant) là, j'ai une partoch de donnée qui est occupé à 96% etc...
                Les gens peuvent avoir envie d'utiliser leur partition pour faire autre chose qu'installer n versions des même trucs parce que certains ont pas remarqué que depuis plus de 5 ans on pouvait faire du 64 bits.
              • [^] # Re: Et maintenant

                Posté par (page perso) . Évalué à 3.

                Pour moi, c’est juste un choix moral. C’est pas parce que j’ai plein de place que je vais la gâcher. C’est pas parce que j’ai plein à bouffer que je vais m’empiffrer et laisser des trucs pourrir dans le frigidaire… C’est pas parce que j’ai plein de places que je vais prendre 150 photos de chaque soirée, et les garder toutes sans m’interroger sur l’utilité ou l’opportunité de la chose. Bref, c’est un choix moral, et c’est le mien, c’est comme ça. Je vois pas pourquoi la technique devrait être imperméable à ma morale.
            • [^] # Re: Et maintenant

              Posté par (page perso) . Évalué à 2.

              Tu m’arraches les mots du clavier…
              Je ne comprends pas cette résistance de certains au 64 bits… On dirait qu’ils sont contents de pas bouger. Le 64 bits, il faut y passer, c’est les processeurs de l’avenir et les système de l’avenir, voilà, c’est comme ça. Ça me rappelle ceux qui comptent encore en francs, tiens… C’est même pas une question d’avantage ou d’inconvénient, c’est juste que c’est comme ça, c’est la nouvelle norme, il faut y passer, point. En plus, le 64 bits a plus d’avantage que d’inconvénients.
              Je suis peut-être hypnotisé, mais chez moi, le changement entre le 32 et le 64 bits s’est vu presque à l’œil nu, tout le système me semble plus fluide et plus rapide.

              Sur le chapitre du 64 bits, le logiciel libre sous Windows est en train de prendre un sacré retard, par rapport au proprio (pas de Firefox, pas d’OpenOffice, pas de VLC…)
              • [^] # Re: Et maintenant

                Posté par (page perso) . Évalué à 1.

                Pas de compilateur … (on me dira que si, mais, je rajoutais cela dans le sens ou MinGW, celui-là qui est utilisé le plus souvent par les logiciels libres, n'a pas encore de version stable pour les Windows 64 bits)
              • [^] # Re: Et maintenant

                Posté par . Évalué à 3.

                Je ne comprends pas cette résistance de certains au 64 bits

                C'est pas une resistance, c'est un choix logique et reflechi: a l'instant t, quelle partie de notre base d'utilisateur utilise un systeme sans aucun support pour le 32bits?

                A partir de la, tu fixes des priorites, sachant que oui, un jour la majorite sera sur un OS pur 64bits et donc il faut se preparer pour ca. Mais comme aujourd'hui c'est extremement faible et que les avantages ne sont pas forcement si important que ca (et tu peux avoir des regressions niveau perfs, genre ton code optimise qui se retrouve a aller bcp plus lentement, ce qui est tres bete...), tu mets d'autres choses en priorite (genre des choses qui vont etre utiles a l'utilisateur final).

                On dirait qu’ils sont contents de pas bouger.

                Vu qu'il y a des builds 64bits, je dirais juste qu'ils ne souhaitent pas pour le moment mettre des gens en QA dessus pour faire des builds officiels. Ils ont deja fait une grosse partie de l'effort, le code est compilable et utilisable en tres grande partie. Je suis sur que les mecs qui bossent sur la version 64bits de la VM JS serait content de savoir qu'en fait ils foutent rien.

                Sur le chapitre du 64 bits, le logiciel libre sous Windows est en train de prendre un sacré retard, par rapport au proprio (pas de Firefox, pas d’OpenOffice, pas de VLC…)

                Et? Deja pour FF c'est faux, il y a des builds 64bits.
                Et ensuite Windows permet d'executer du code 32bits de facon 100% transparente pour l'utilisateur, donc on s'en fout totalement.
  • # moi aussi! moi aussi!

    Posté par . Évalué à 4.

    Testé chez moi avec pas mal de navigateurs.
    dual core Intel T2050 1.60Ghz

    firefox 3.5.5
    Peacekeeper: 1030 pts
    SunSpider: 2472.0 ms

    firefox 3.6b1
    PeaceKeeper: 1414 pts
    SunSpider: 2010.8 ms

    firefox 3.7a1pre
    PeaceKeeper: 1559 pts
    SunSpider: 1756.0 ms

    Chromium 4.0.270.0
    PeaceKeeper: 2281 pts
    SunSpider: 1023.4 ms

    Opera 10.10
    PeaceKeeper: 875 pts
    SunSpider: 8803.6 ms

    uzbl 20090916 webkitgtk-1.1.12
    PeaceKeeper:
    SunSpider: 1607.6 ms

    Konqueror 4.3.3
    PeaceKeeper: 836 pts
    SunSpider: 6887.0 ms

    Seamonkey 2.0
    PeaceKeeper: 1050 pts
    SunSpider: 2612.2

    uzbl, Konqueror et SeaMonkey ont été compilés par moi ou ma distribution. Les autres sont les binaires officiels.
    uzbl ne finit pas le test Peacekeeper par contre. Il s'arrete sur le bidule ou on voit normalement des recherches sur une pseudo interface en ligne défiler à toute vitesse. La il se passe rien.
    Sinon chrome est effectivement rapide, et ça se ressent à l'utilisation, mais sans adblock et avec une gestion pas très fine des cookies. Je continuerai d'utiliser firefox personnellement. D'autant que ses performances augmentent de version en version d'après les benchs.
    Les résultats sont bizarres pour Opera aussi. À l'utilisation il est très véloce pourtant.
    uzbl à beau être très rapide sur le papier. Dans la pratique je le trouve assez lent (beaucoup plus qu'opera)
    • [^] # Re: moi aussi! moi aussi!

      Posté par . Évalué à 2.

      • [^] # Re: moi aussi! moi aussi!

        Posté par . Évalué à 3.

        Oui, et tu as donne a l'extension l'acces a ton historique et tes donnees perso?

        Etre oblige de donner acces a tout juste pour bloquer les pubs, comme modele de secu, ca fait peur... (ok, pareil pour FF, mais la on parle de chrome qui fait sa pub sur la secu et la separation en processus differents pour chaque tab)

        (oui le code source est dispo, mais as tu ete lire le code source de l'appli pour etre sur qu'il n'y a pas de backdoor? mmmhhh?)
    • [^] # Re: moi aussi! moi aussi!

      Posté par . Évalué à 1.

      > Chromium 4.0.270.0
      > SunSpider: 1023.4 ms

      > uzbl 20090916 webkitgtk-1.1.12
      > SunSpider: 1607.6 ms

      Tiens, marrant, chez moi c'est webkit-gtk le plus rapide (quoique de peu, cf. mon commentaire plus bas). Mais mon Chromium est un peu plus vieux que le tiens, et mon webkit-gtk, au contraire, un peu plus récent... Je serais curieux de savoir lequel des deux a récemment fait les progrès qui expliqueraient la différence entre nos résultats.
  • # Qlqs résultats sunspider sur x86_64

    Posté par . Évalué à 4.

    Allez zoup, moi aussi je veux jouer, voilà mes résultats à sunspider. Rien de bien neuf par rapport à ce qui a déjà été constaté, juste une confirmation que le JS sous Firefox en 64bits, c'est pas encore ça...

    Tests effectués sous Gentoo / GCC 4.4, sur un "Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz".

    - Firefox 3.5.5 (CFLAGS Mozilla, donc en gros "-Os"): 3193.0ms +/- 2.6%

    - Firefox 3.5.5 (CFLAGS perso, donc en gros "-O2"): 3125.4ms +/- 2.0%
    (pas une grosse différence au global, mais dans le détail, sur quelques tests, c'est très significativement mieux ou pire -- je suppose qu'en PGO on arriverait, en gros, à ne garder que le meilleur)

    - Firefox 3.5.5 (binaires 32 bits): 1839.0ms +/- 2.0%
    (ah bah oui, l'effet TraceMonkey si j'ai bien compris les commentaires précédents...)

    - Firefox 3.6_beta4 (CFLAGS Mozilla, donc en gros "-Os"): 2875.0ms +/- 0.9%
    (la révolution n'est pas encore pour cette version)

    - Konqueror 4.3.4: 3423.4ms +/- 2.1%
    (ça fait plaisir d'en voir un derrière Firefox)

    - Chromium 4.0.266.0: 572.2ms +/- 4.6%
    (ah, c'est vrai que ça va vite ce truc)

    - Uzbl 0_pre20091130 (webkit-gtk 1.1.15.4): 545.4ms +/- 1.2%
    (rien à voir, mais je trouve que ce navigateur minimaliste, que je ne connais que depuis environ une semaine, est bien sympathique en appoint de Firefox)

    - Epiphany 2.28.1 (webkit-gtk 1.1.15.4): 529.4ms +/- 0.6%
    (cohérent avec le résultat sur Uzbl -- chapeau Webkit, tu es "the winner")


    Enfin bon, après, à chacun d'en faire ce qu'il veut de ces résultats. Perso, je vais pas changer mes habitudes juste pour ça : je garde mon Firefox comme navigateur principal, parce que je suis accro à moultes de ses fonctionnalités et extensions. Et je ne passe pas ma journée sur Google Wave ou autre application bling-bling en ligne, donc je peux supporter une exécution du Javascript qui se contente d'être raisonnablement rapide dans les cas classiques. Si par contre je pouvais trouver le truc pour qu'il arrête de faire gratter mon dur quand je me contente de lire une page¹, ça me ferai bien plus plaisir que toutes les optimisations Javascript du monde en fait.

    ¹ màj du sessionstore.js, où l'information essentielle que constitue mon niveau de scroll de chaque page ouverte est religieusement stockée toutes les 10 secondes. Oui, je peux baisser ce délai, mais idéalement je préférerai le conserver pour les choses importantes, et omettre celles superflues.
    • [^] # Re: Qlqs résultats sunspider sur x86_64

      Posté par . Évalué à 8.

      > màj du sessionstore.js, où l'information essentielle que constitue mon niveau de
      > scroll de chaque page ouverte est religieusement stockée toutes les 10 secondes.
      > Oui, je peux baisser ce délai, mais idéalement je préférerai le conserver pour les
      > choses importantes, et omettre celles superflues.

      Comme quoi ça a du bon de gronchonner sur linuxfr, parce que après on se dit qu'on va se prendre un "fait un patch", alors on le fait, et voilà :
      https://bugzilla.mozilla.org/show_bug.cgi?id=506482#c8
      • [^] # Re: Qlqs résultats sunspider sur x86_64

        Posté par . Évalué à 2.

        Génial !!!

        Il faut que tu demandes une review sur ton patch maintenant :)
        • [^] # Re: Qlqs résultats sunspider sur x86_64

          Posté par . Évalué à 2.

          Merci pour ton commentaire, j'étais pas au courant de ce process pour la gestion des patches. Pour les curieux qui, comme moi, n'avaient jamais contribué à bugzilla.mozilla.org, les explications sont là:
          https://developer.mozilla.org/En/Developer_Guide/How_to_Subm(...)
          Btw, j'ai aussi découvert dans cette doc que je devrais accompagner ma modif d'un test unitaire, mais après avoir un peu galèré pour faire démarrer mochitest, j'arrive toujours pas à atteindre la fin de la testsuite existante (ça se fige en cours de route avec le brouteux à 100% CPU), donc pour l'instant je vais laisser ça de côté...
    • [^] # Re: Qlqs résultats sunspider sur x86_64

      Posté par (page perso) . Évalué à 2.

      Et moi aussi.

      Chrome ( 4.0.249.30 ): 613ms
      Midori ( 0.1.9 ): 889ms
      Firefox 32 ( 3.5.5 ): 1333ms
      Rekonq ( 0.2.0 ): 1904ms
      Arora ( 0.10.1 ): 2058ms
      Kazehakase ( 0.5.8 ): 2614ms
      Firefox 64 ( 3.5.5 ): 2741ms
      Epiphany ( 2.26.1 ): 2903ms
      Konqueror ( 4.3.2 ): 3509ms

      Je suis étonné qu'il y ait une telle variété de résultat. J'aurais pensé que j'aurais au moins deux fois le même résultat (peut-être que Firefox 64 bits et Kazehakase sont basé sur les même versions de moteurs).
  • # J'ai rien compris.

    Posté par (page perso) . Évalué à 5.

    >> Il est 5.3x plus lent (...) étant 2.6x plus rapide (...) ne gagne "que" 20%

    Bien.
    Au final, j'ai rien compris. T'aurais du aussi rajouter « met 1 seconde de moins » histoire de bien m'embrouiller.

    Sinon, un tableau de résultats, avec « 1 » pour le temps de référence, t'as pas ça sous la main ? Car ton journal est indigeste là :/


    >> Q2: Savez vous ce qui explique cette différence pharamineuse ?

    La malédiction du faraon.
    (Je connaissais pas cette orthographe -->[  ])
  • # des reponses

    Posté par (page perso) . Évalué à 10.

    Pourquoi donc une version linux plus lente que sous windows.


    1) bon déjà, faudrait tester des navigateurs de même génération. Comparer un Chromium 4 qui vient de sortir, à une "vieille" version de Firefox, c'est limite. Car en ce moment, les progrés sont énormes ET très rapide. Bref, vaut mieux comparer avec une beta 3.6 de Firefox.

    2) comme ça été dit, TraceMonkey n'est pas activé en 64bit dans la version 3.5 de Firefox, mais l'est à priori dans la version 3.6. d'où de grosse différence, puisque c'est alors l'ancien moteur JS non optimisé (SpiderMonkey) qui est utilisé

    3) comme je l'ai déjà dit dans un autre commentaire, il n'y a pas de "branche" spécifique à linux ou à windows. C'est le même code, le même trunk. Les deux versions partagent au moins 90% du code, parce que l'objectif de Mozilla (depuis 1998) est justement de limiter de recoder les mêmes trucs pour chaque plateforme. Ainsi donc, c'est exactement le même moteur de rendu, le même moteur JS, la même implémentation DOM, les mêmes sources pour l'interface en XUL (modulo les fichiers CSS et quelques aménagements, comme l'emplacement de l'item de menu Options et autre trucs mineurs de cet acabi) etc..

    Et tout ça repose sur une même couche d'abstraction du système, que ce soit d'un point de vue graphique (lib Cairo), ou plus général (fichiers, threads, et cie : lib NSPR)

    La grosse différence entre les deux, se situe donc dans l'implémentation de cette couche d'abstraction, tant dans Cairo que NSPR, mais aussi dans le toolkit utilisé (GTK sous linux, win32 sous windows et cie)

    Bref, au final, les différences de perfs entre Windows et Linux, se situent principalement dans les accés au système et à l'environnement graphique. De là à dire que le sous-systeme graphique de Windows est plus performant que X... ;-)
    Notons aussi que sous linux, on a les problemes de fsync (notament via sqlite). Dans la 3.6, ils ont alors essayé de limité au maximum les accés disques et les requetes SQL, pour palier à ce défaut.

    Bref, la faute n'est pas entièrement celle de Mozilla, mais de aussi des libs externes utilisées.

    4) la compilation. Sous windows, c'est Visual C++ qui est utilisé. Sous les autres système, GCC. Il parait que VC produit souvent du code mieux optimisé que GCC. Ceci explique peut être cela.

    D'une distro à une autre, les libs externes utilisées (sqlite et cie), ne sont pas forcément la même version qu'utilisée dans les builds windows, (qui sont celles largement testées et validées par Mozilla). Peut-être alors a-ton des différences de perfs parce qu'utilisation de libs différentes (plus ancienne par ex). Pure supposition de ma part. Notons aussi que sous windows, tout est compilé en statique.

    5) possible que la différence se fait sentir à cause aussi des différences entre options de compil, entre chaque distro et os. Possible aussi que les patchs ajoutés par certaines distro aient des effets de bords..

    6) reste aussi le temps passé à optimiser la version Linux. Il y a des développeurs sous linux, mais comme dit Pascalc plus haut, peu de retour, peu de beta testeur, et ne représentent même pas 1% de tout les betas testeurs. Moins de retours -> moins de bug de perf "découverts". D'ailleurs, il est probable que bon nombre de ces 1% des betas testeurs utilisent les binaires vanilla de Mozilla (compilé en static, sans patchs et autre options de compil exotiques), donc peut être avec moins de différences flagrantes. ça rejoint le point 5.

    Bon, et sinon, ça râle régulièrement sur ce site, à propos des perfs sous linux (souvent à juste titre, c'est vrai). Mais râler ne suffit pas. Il faut aussi des gens pour tester et pour coder. Alors n'hésitez pas à contribuer ;-)
    • [^] # Re: des reponses

      Posté par . Évalué à 4.

      Merci pour ta réponse. Mon journal n'était pas là pour déclencher une guerre: il partait simplement du constat que le firefox 64 bits sous linux que j'utilisais était 2.5 fois plus lent sous linux que sous windows. Maintenant que la discussion a eu lieu, je comprends les tenants et les aboutissants, et je suis passé à 3.7a1pre pour compenser, et le gain est très visible.

      Cela dit, tu avoueras que c'est difficile de ne pas se sentir trahi quand la même version du navigateur est dépourvue de certaines améliorations d'un binaire à un autre (32 vs 64 bits), sans que ce soit clairement explicité - ou alors je l'ai manqué, et si c'est le cas il faut me dire où regarder la prochaine fois :)

      D'ailleurs, je ne suis pas le seul à l'avoir ratée, cette explication: il a fallu attendre 40 commentaires pour voir émerger la bonne réponse et les 39 premiers ont relayé les légendes urbaines, habituelles et tenaces, qui polluent la com autour de Firefox en lui faisant porter un poids duquel il n'est pas responsable. Y'a du progrès à faire là dessus, et je vais continuer à y contribuer à mon échelle, enrichi de ces points qui ont été soulevés.

      Pr info, je suis moi même un fervent utilisateur de FF, et je contribue aussi volontiers au retour de bug, dès que 3.7a1pre me posera problème. Rien à signaler pour l'instant.
    • [^] # Re: des reponses

      Posté par . Évalué à 4.

      De là à dire que le sous-systeme graphique de Windows est plus performant que X... ;-)

      Il a déjà été dit que Chrome et Opera sont aussi vifs sous Windows que sous Linux, cet argument ne tient donc pas.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: des reponses

        Posté par . Évalué à 4.

        Si c'est vrai que le delta est moins important que pour Firefox, désolé mais Chrome pour Windows est plus rapide dans ma VM XP qu'en natif dans Linux.

        Apparemment Chrome forke de manière intensive des librairies système qu'il compile en statique, ce n'est pas la politique de Mozilla qui préfère travailler upstream.

        Tu as un billet du packageur Fedora de Chrome ici qui explique pourquoi Chrome/Chromium ne deviendra pas un paquet officiel pour leur distro:

        http://spot.livejournal.com/312320.html

        "Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use."
      • [^] # Re: Chromium plus rapide sous Linux que sous Windows ?

        Posté par (page perso) . Évalué à 2.

        D'après un article de Slashdot datant du 3 novembre 2009, la version X11 de Chromium surpasserait les versions Windows et Mac. L'article fait référence un à un billet intitulé « Pourquoi Linux Chrome est aussi rapide » posté le 28 octobre 2009 sur le groupe « Chromium-dev », où un développeur suppose que l'utilisation de certaines capacités de X11 évitent beaucoup des memcpy() présents sur la version Windows.

        http://tech.slashdot.org/story/09/11/03/1334203/X11-Chrome-R(...)
        http://groups.google.com/group/chromium-dev/browse_thread/th(...)

        D'un autre côté un article plus ancien publié sur le site TuxRadar, publiait un test de performance en février 2009 qui montrait que la version Windows de Firefox 3 exécutée sous Wine était plus rapide que la version native Linux de Firefox 3 :
        http://tuxradar.com/content/browser-benchmarks-2-even-wine-b(...)
    • [^] # Re: des reponses

      Posté par . Évalué à 2.

      Notons aussi que sous linux, on a les problemes de fsync (notament via sqlite)

      Sauf erreur de ma part, c'est désactivable (cf. « PRAGMA synchronous »).
  • # Arch

    Posté par . Évalué à 3.

    Pour la petite histoire, j'ai testé Firefox et Chromium sous Arch, et SunSpider est _nettement_ plus rapide que sous Kubuntu.

    Chromium : 419ms
    Firefox-3.6 beta 2 : 1005.6ms.

    Je n'ai plus le chiffre exact en tête pour FF-3.6 sous kubuntu, mais c'était assez proche des 2 secondes. Il faut dire que le Firefox de Arch est compilé avec PGO, mais pour avoir cette performance, j'imagine que tracemonkey y est vraisemblablement activé même en x86_64.

    D'ailleurs, c'est ma première demi journée sous Arch, et je constate que tout semble perceptiblement plus rapide. Évidemment, pas mal de configuration se fait à la main, mais ça n'a pas que des inconvénients et les docs que j'ai vues jusqu'à présent sont très bien faites :)

Suivre le flux des commentaires

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