Journal Chromium est bien plus lent que Firefox

Posté par (page perso) .
Tags : aucun
19
24
jan.
2010
Chromium est bien plus lent que Firefox, mais dans certaines utilisations.

Je travail actuellement sur un ordinateur en export display, à travers un tunnel ssh. En utilisant la commande ssh -X.

J'utilise Firefox, qui est tout à fait utilisable, du moment que le tunnel passe par un réseau local performant. Le défilement est utilisable, bien qu'un peu saccadé. Les boutons réagissent rapidement à la souris, l'interface est aussi réactive que sur les autres applications, bref, l'export display, c'est super.

Par curiosité, j'ai voulu testé Chromium dans ces mêmes conditions. Et là, c'est le jour et la nuit. L'application est plus lente à lancer que Firefox, car l'interface clignote lentement au démarrage. Le chargement des sites est super saccadé, l'icône du chargement est lui aussi saccadé. Le défilement est inutilisable, la page est mise à jour toutes les secondes. Les boutons survolés sont affichés avec beaucoup de retard. L'interface réseau est saturée. Bref, c'est inutilisable, et j'ai l'impression que toute la fenêtre Chromium est transférée comme un gros bitmap à travers le serveur X.

Pensant que cela pouvait venir de webkit, le moteur graphique de Chromium, je teste avec Midori, un autre navigateur web utilisant webkit. Et là, tout est fonctionnel, encore plus réactif que Firefox.

Donc, maintenant je pense savoir pourquoi Chromium est plus réactif que Firefox sur linux. Les gens de chez Google trichent avec X11 en passant des gros bitmaps, au lieu d'objets vectoriels plus lourds à traiter pour le serveur, mais supérieurs techniquement.

Pour l'anecdote, les éléments en position fixe sur une page web, comme par exemple la barre d'outils de linuxfr, sont très lent sur X11 car ils sont mis à jour en deux temps. Lors d'un défilement, on voit toute la page défiler et ces éléments défiler eux aussi, puis dans un deuxième temps, ils sont remis à leur position respective. C'est un petit soucis d'optimisation de gecko qu'il n'y a pas du tout sur webkit avec Midori.

Voilà, c'était l'information inutile du dimanche.
  • # Et beh...

    Posté par . Évalué à -9.

    Quand on tombe aussi bas pour défendre ff face à chrome, on se dit c'est vraiment mal barré pour le renard de feu (bientôt dénommé feu le renard).
    Le nouveau netscape va mourir, une nouvelle fois abattu par un logiciel propriétaire. Mais c'est un phénix qui renaîtra encore de ces cendres avec une lourdeur de dragon de komodo dans le futur moteur aussi lent que ses prédécesseurs.

    Et sinon dans le même genre t'as essayé avec ie et safari émulés avec wine ? Parce que là ça me ferait carrément changer de navigateur je crois<;
    • [^] # Re: Et beh...

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

      Chromium_%28navigateur_web%29 est libre, même si le modèle clairement affiché de Google_Chrome est propriétaire.
      • [^] # Re: Et beh...

        Posté par . Évalué à 5.

        Faudrait vraiment fixer les liens wikipedia sur ce site, c'est généralement plus compliqué de faire un lien wikipedia que de copier coller l'url directement.

        Vivement la nouvelle version.
    • [^] # Re: Et beh...

      Posté par . Évalué à 4.

      Tu ne fréquenterais Frédéric Mitterrand, par hasard ?
    • [^] # Re: Et beh...

      Posté par . Évalué à 4.

      Même si je ne suis pas d'accord avec toi, je kiffe ton style grave sa race !

      « 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 »

  • # J'ai ma réponse !

    Posté par . Évalué à 3.

    "Pour l'anecdote, les éléments en position fixe sur une page web, comme par exemple la barre d'outils de linuxfr, sont très lent sur X11 car ils sont mis à jour en deux temps. Lors d'un défilement, on voit toute la page défiler et ces éléments défiler eux aussi, puis dans un deuxième temps, ils sont remis à leur position respective. C'est un petit soucis d'optimisation de gecko qu'il n'y a pas du tout sur webkit avec Midori."
    Mais ce bug n'est plus ! C'est donc que X11 et/ou Gecko ont été corrigés, non ?
    • [^] # Re: J'ai ma réponse !

      Posté par . Évalué à 6.

      X11 n'a rien à voir dans l'histoire, c'est au navigateur de ne pas déplacer les éléments fixes lors du scroll :)
  • # Retour d'expérience pour une utilisation plus conventionnelle.

    Posté par . Évalué à 3.

    Bonjour,

    Je suis moi même pas mal intéressé par l'évolution de Chromium. Je l'ai donc installé il y à quelques temps sur ma machine et je dois dire que dans mon cas, j'ai des soucis de stabilité (onglets qui bloquent / crashent). Mais bon, le soft est jeune et en plein développement, je peux comprendre les instabilités.

    Point plus intéressant :
    Pour les fois où ce dernier voulait bien fonctionner, je l'ai testé en ajoutant l'extension adBlock, et là, il n'y a pas photo. Firefox est plus rapide (ou Chromium devient vraiment très lent, au choix).

    L'extension adBlock(+) étant pour moi incontournable, chromium ne remplacera pas firefox de si tôt.
    • [^] # Re: Retour d'expérience pour une utilisation plus conventionnelle.

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

      Est-ce que tu a essayé avec l'extension AdThwart pour voir si il y a une différence de rapidité par rapport à AdBlock ?
      • [^] # Re: Retour d'expérience pour une utilisation plus conventionnelle.

        Posté par . Évalué à 1.

        Non, pas essayé, j'essaierai quand j'aurai à nouveau un chromium fonctionnel ;)

        Je ne connais pas cette extension, elle est aussi efficace que adBlock ?
        • [^] # Re: Retour d'expérience pour une utilisation plus conventionnelle.

          Posté par . Évalué à 4.

          Je serais curieux d'avoir des retours autre que le mien.

          Car j'ai utilisé AdThwart, Adblock, etc. (comprendre quasiment toutes les extensions anti-pubs sous Chrome) et avec le même filtre que sous Adblock Plus de Firefox (EasyListFr) et sous Chrome ça fonctionne _vachement_ moins bien. Je vois encore plein de pubs.

          De plus sous Chrome les extensions sont désactivées avec le porn^W private mode donc tu te tapes toutes les pubs :)
          • [^] # Re: Retour d'expérience pour une utilisation plus conventionnelle.

            Posté par . Évalué à 2.

            Ça doit être bien embêtant quand tu vas acheter un cadeau pour un proche sans qu'il le sache. Parce que les sites de e-commerce sont bourrés de pub...

            Knowing the syntax of Java does not make someone a software engineer.

          • [^] # Re: Retour d'expérience pour une utilisation plus conventionnelle.

            Posté par . Évalué à 2.

            Il faudrait une liste d'autorisation, mais ça semble partir d'un bon sens.
            En effet les développeur de chrome connaisse leur code et peuvent donc dire qu'il n'y a pas de faille (disons à leur connaissance). C'est loin d'être le cas pour les extensions.
            Il y avait même eu une petite campagne me semble-t-il il y a quelque temps (années), visant à se méfier des extensions de firefox pour la sécurité, qu'il n'y a pas de contrôle dessus.
            Alors, désactiver les modules en privé, ça ne me semble pas entièrement sans intérêt, surtout quand on est sur la machine de quelqu'un d'autre et que l'on ne sait pas ce que pourrait loger telle ou telle extension.
  • # Pas du tout mon expérience

    Posté par . Évalué à 7.

    Chromium est clairement le navigateur le plus rapide au niveau du rendu, de javascript (v8 est une merveille), et de l'IHM.
    Chose qui m'a surpris le WebKit embarqué par Chromium est beaucoup plus rapide que QtWebKit ou WebKitGtk, d'un côté ça s'explique par le moteur de dessin différent(Cairo, Arthur) mais de l'autre la différence est flagrante que ce soit avec Arora ou Midori.

    Les raisons qui font que je n'utilise pas Chromium comme navigateur par défaut sont :
    * consommation mémoire plus importante (évidemment, c'est du multiprocessus). Sur une machine dédié à la navigation web, la rapidité de Chromium doit compenser mais ça rentre pas dans mon cadre d'utilisation.
    * les extensions moisies qui s'intégrent super mal à l'IHM.
    J'aime beaucoup l'IHM de Chromium, l'adjectif qui à mon goût la caractérise le mieux est "slick", très peu d'espace perdu, jamais de ralentissement, pas aggressive mais pas adapté aux extensions.
    * gestion des marques-pages moisies, la synchronisation (multi-navigateurs/plateformes) avec Chromium est particulièrement pénible, celui-ci imposant sa façon de faire.
    * compatibilité avec les noyaux aléatoire: parfois, il ne se lance pas, parfois, pas de rendu, ça m'a surpris. Mais vu la taille des sources, j'ai même pas essayé à résoudre le problème.

    La raison pour laquelle, je ne le recommande plus aux débutants sous GNU/Linux est l'immaturité de l'intégration des plugins propriétaires. Même si j'en ai rien à foutre personnellement, je me dois un minimum de courtoisie.

    Même si Firefox 3.6 est loin d'avoir rattrapé son retard au niveau des performances, il offre une expérience de qualité en terme de navigation web (multitude d'extensions bien intégré), et une consommation mémoire qui redevient de plus en plus raisonnable.
    FF n'a pas besoin qu'on raconte des conneries sur la concurrence, Chromium est loin d'être parfait et FF possède ses propres qualités.


    > Les gens de chez Google trichent avec X11 en passant des gros bitmaps
    Les développeurs de Fennec utilisent la même astuce, en quoi est-ce de la triche si ça améliore l'expérience de navigation ? // par ailleurs, je ne saurais dire si Chromium utilise effectivement cette astuce.
    • [^] # Re: Pas du tout mon expérience

      Posté par . Évalué à 2.

      de toute façon le postulat de départ "chromium est bien plus lent que firefox" ne vaut pas grand chose, c'est dans un cas très particulier, et qui utilise encore l'export display, quand des solutions bien plus rapides et efficaces existent, comme vnc ou nx ?

      "ssh -X est bien plus lent que NX" !

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Pas du tout mon expérience

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

        NX est plus performant que l'export simple de X11 par une compression habile du protocole. Mais je serais surpris d'apprendre que nx soit réellement plus efficace sur des bitmaps !

        Et comparé à VNC, ben je préfère encore l'export X11.
        • [^] # Re: Pas du tout mon expérience

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

          « Je serais surpris d'apprendre que nx soit réellement plus efficace sur des bitmaps »

          Si il l'est. Il fait une légère compression JPEG dessus. Ça se voit un peu mais je préfère largement ça aux saccades.
      • [^] # Re: Pas du tout mon expérience

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

        VNC plus rapide et plus efficace qu'un export display ? C'est pas vraiment comparable. VNC, c'est bon pour dépanner à distance ses grands parents quand ils sont devant l'ordinateur, mais je me vois mal bosser toute une journée sur un truc qui saccade, et qui n'est qu'une petite fenêtre mal intégrée à son environnement de travail.

        Après, que NX soit plus performant que ssh -X, c'est normal, c'est le but. Maintenant, sur un réseau local, la différence ne doit pas être si grande, surtout pour recevoir des bitmaps.

        Envoyé depuis mon lapin.

        • [^] # Re: Pas du tout mon expérience

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

          VNC, c'est bon pour dépanner à distance ses grands parents quand ils sont devant l'ordinateur, mais je me vois mal bosser toute une journée sur un truc qui saccade, et qui n'est qu'une petite fenêtre mal intégrée à son environnement de travail.

          Je ne sais pas de quel VNC tu te sers, mais il y a des serveurs VNC conçus pour le réseau local qui sont très rapides. C'est simple: l'utilisateur ne sait pas que son bureau est en VNC ou qu'il accède à une application via VNC.
          Regarde le système de client léger de Cendio.com par exemple.

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

        • [^] # Re: Pas du tout mon expérience

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

          « Maintenant, sur un réseau local, la différence ne doit pas être si grande, surtout pour recevoir des bitmaps. »

          Détrompe-toi.

          Lorsque j'ai commencé à travailler en déporté sur mon réseau local j'ai d'abord utilisé un export simple, ça fonctionnait bien pour certaines applis et très mal dans d'autres. Par exemple, sous Firefox, lorsqu'on ouvre la barre d'adresse (« Awesome bar »), le résultat était un véritable supplice, sans raison apparente.

          Sous NX avec un réseau local je n'ai _jamais_ vu une appli saccader ou une quelconque latence apparaître (sauf quand ça vient de l'appli elle-même évidemment).

          Note : c'est du Gigabit Ethernet de bout en bout et je suis tout seul dessus.

          Bon par contre il arrive parfois qu'il apparaisse quelques glitches graphiques sous NX (genre des traits qui restent lorsqu'on ferme un menu), mais ça n'a rien de vraiment gênant. Par contre ce qui est plus problématique c'est qu'il n'aime pas du tout VirtualBox (l'affichage de la VM est quasiment inexploitable), mais j'avoue n'avoir pas (encore) cherché pourquoi, ça pourrait aussi bien venir de mon WM pour ce que j'en sais.
    • [^] # Re: Pas du tout mon expérience

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

      L'inclusion des bibliothèques dans le code (et adaptations spécifiques à chromium) plutôt que par des appels dynamiques et remontée de patchs upstream est encore d'actualité a priori (ce qui complique l'intégration et a fait dire à quelques-uns que c'était les "mauvaises habitudes" de développeurs java qui avaient été reprises ;-) ) :
      http://www.ostatic.org/blog/making-projects-easier-to-packag(...)
      http://spot.livejournal.com/312320.html [en] les explications plus détaillées
      • [^] # Re: Pas du tout mon expérience

        Posté par . Évalué à 4.

        C'est clair que Chromium est une vraie plaie niveau packaging. À l'argumentaire de Spot, je rajouterais que les mainteneurs de Chromium sont loin d'être coopératifs avec les intégrateurs.

        Chromium supporte le codec H264 en lieu et place de Theora pour la balise video ce qui pose problème pour les distributions libres. Récemment, Bastien Nocera avait proposé d'intégrer GStreamer pour la gestion du multimédia à Chromium la réponse de Google a été une fin de non recevoir sèche.
        http://code.google.com/p/chromium/issues/detail?id=32861 (on notera que le dev Google confond allégrement Chrome et Chromium) ---> youpi -_-
        • [^] # Re: Pas du tout mon expérience

          Posté par . Évalué à 1.

          Ton résumé est un peu biaisé je trouve, il a deux arguments:
          - la portabilité là effectivement il se plante
          - la sécurité et là c'est un réel problème technique que tu passe bien allégrement sous le tapis je trouve..

          Ceci dit comme le dit un commentaire, ce n'est probablement pas insoluble comme problème, mais cela parait loin d'être évident..
  • # Pas non plus du tout mon expérience

    Posté par . Évalué à 6.

    Chez moi :
    * L'UI de FF est très lente. Dans une liste avec 20 bookmarks, la ligne sélectionnée ne suit pas le pointeur suffisamment rapidement. Dans Chromium, ça juste-marche, comme attendu.
    * Le défilement de FF est très lent. Si on défile rapidement à la molette dans une page un peu grosse (p.ex. une longue page de Wikipédia), FF n'a le temps de calculer que 2 ou 3 étapes intermédiaires entre le début et la fin de la page. Avec Chromium, le défilement est fluide.
    * L'édition de grosses pages de Wikipédia est inutilisable. Je tape mon texte, puis je vais chercher un café et je regarde FF entrer un par un les caractères que j'ai entrés. (Même avec la correction d'orthographe désactivée). Avec Chromium, ça marche avec la rapidité attendue, même en activant la correction orthographique.
    * FF est très lent à se redessiner quand on change de bureau. Merci à l'auteur du journal de me signaler que Chromium passe un gros bitmap. Ignorant que j'étais, je pensais que c'était toujours fait comme ça et je ne comprenais pas pourquoi FF se redessinait lentement par petits morceaux au lieu, comme Chromium, d'apparaitre rapidement et en un seul bloc. Dessiner des bitmaps c'est bien le truc que X sait faire le mieux ; pourquoi demander à Gecko de tout recalculer à chaque fois (lentement), alors que rien n'a changé et que X peut afficher tout ça super rapidement ? [1]

    [1] http://linuxfr.org/2005/12/22/20106.html#664165
    • [^] # Re: Pas non plus du tout mon expérience

      Posté par . Évalué à -5.

      pourquoi demander à Gecko de tout recalculer à chaque fois (lentement), alors que rien n'a changé et que X peut afficher tout ça super rapidement ?

      Parce que les dev de Firefox n'en ont rien à foutre de Linux. Et la raison, c'est que Linux c'est moins de 5% de leur utilisateurs.

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

    • [^] # Re: Pas non plus du tout mon expérience

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

      Je me suis plus où moins retrouvé dans le même cas d'utilisation que toi, et je n'ai pourtant pas constaté les mêmes désagréments, mon défilement est fluide y compris de de longue page contenant des image et du contenu dynamique, et je n'ai aucun soucis avec l'édition de page wikipédia longue et complexe.

      En particulier j'utilise abondamment les bookmarks, j'en ai plus de 1200 actuellement et certaines de mes catégories en contiennent presque 100 et je n'ai aucun soucis de ralentissement.
      • [^] # Re: Pas non plus du tout mon expérience

        Posté par . Évalué à 2.

        Il parait que FF est spécialement lent sous architecture 64 bits, ce qui est mon cas.
        • [^] # Re: Pas non plus du tout mon expérience

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

          C'est normal, il n'y a pas encore de JIT en 64 bits. C'est le même interpreteur que FF 3.0

          « 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: Pas non plus du tout mon expérience

            Posté par . Évalué à 2.

            Tous mes tests sont effectués en désactivant javascript, aussi bien avec Chromium que FF.

            (Je ne suis pas sûr de savoir ce dont tu parles, mais une recherche google sur JIT pointe vers l'interpréteur javascript.)
    • [^] # Re: Pas non plus du tout mon expérience

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

      L'édition de grosses pages de Wikipédia est inutilisable. Je tape mon texte, puis je vais chercher un café et je regarde FF entrer un par un les caractères que j'ai entrés. (Même avec la correction d'orthographe désactivée).
      *


      Chez moi, les problèmes de rapidité d'édition de champs texte provenait de Adblock Plus. Mets Wikipédia dans ta liste blanche pour voir...
  • # c'est le cache du serveur X

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

    Je suppose que Chromium se sert de la même "optimisation" facile que les versiosn précédents de Firefox, d'OpenOffice, Kpdf, etc. En gros, le rendu graphique est plus rapide si on sert du cache du serveur X.
    Ainsi, il y a eu les mêmes soucis que toi sur LTSP avec des version précédentes de Firefox (autour de la 2.5 je crois ?) et d'autres applications qui abusent de la mémoire X server afin de mettre en cache le rendu graphique. Il y a des résultats de tests ici:
    http://www.mille-xterm.org/en/TerminalMemoryUsage
    Depuis, les developpeurs de Mozilla et d'OpenOffice.org ont réagi (avec les versions 3.X).

    Par ailleurs, as-tu testé sans passer par un tunnel ssh ? Sur LTSP (linux terminal serveur project) on peut faire avec ou sans et ça change un peu...

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

  • # Chromium est bien plus lent que Firefox

    Posté par . Évalué à 6.

    « je pense savoir pourquoi Chromium est plus réactif que Firefox sur linux. Les gens de chez Google trichent avec X11 en passant des gros bitmaps, au lieu d'objets vectoriels plus lourds à traiter pour le serveur, mais supérieurs techniquement. »

    optimiser, c'est tricher ?

    « 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: Chromium est bien plus lent que Firefox

      Posté par . Évalué à 1.

      L'optimisation, c'est fait pour accélérer, non ?
      • [^] # Re: Chromium est bien plus lent que Firefox

        Posté par . Évalué à 2.

        Tiré d'un commentaire précédent : http://www.mille-xterm.org/en/TerminalMemoryUsage « practice is that some applications abuses of the X server memory for caching, rendering and such. This is usualy a good optimization on a fat client, but not on a thin client. »

        Après c'est sûr, si tu utilises chromium via VNC sur une connection modem 4Kbps, tu n'utilises pas forcément le(s) bon(s) outil(s) le(s) mieux adapté(s) et rien ne t'empêche de changer.

        « 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: Chromium est bien plus lent que Firefox

        Posté par . Évalué à 1.

        Parfois, l'optimisation, c'est cibler certaines cibles particulières pour accélérer dans ces situations là, oui.
        • [^] # Re: Chromium est bien plus lent que Firefox

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

          Le poids des pages web augmentant (haut débit, javascript à la tonne, flash et vidéos partout), ce genre "d'optimisation" bouffe de plus en plus de mémoire. Pas besoin d'être en affichage déporté pour crasher X sans raison apparente.

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

          • [^] # Re: Chromium est bien plus lent que Firefox

            Posté par . Évalué à 1.

            Euh, si X se crashe c'est la faute des applications utilisatrices??

            Curieux moi je dirais que dans ce cas la c'est plutôt les developpeurs d'X qui en sont "responsables", robustesse du codage, tout ça..
            • [^] # Re: Chromium est bien plus lent que Firefox

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

              Certaines applications (suites bureautiques, navigateur web, lecteur pdf) utilisent le cache local de XWindow, pour optimiser la vitesse d'affichage. Elles ne devraient pas. Ça pouvait passer autrefois, mais avec la consommation de Ram qui grimpe en flêche depuis quelques années, on constate que l'application bouffe tout le cache disponible, ce qui provoque à tous les coups un plantage de X.

              Ça se voit très bien quand tu fais du terminal-serveur. On a des clients légers, qui ne servent qu'à l'affichage déporté. Or les applications qui utilisent le cache du serveur X local, donc celui du client léger, font parfois planter le client léger (déconnexion). Pour pallier à ça, LTSP.org (Linux Terminal Server Project) dispose d'un paramètre pour tuer l'application qui consomme trop de Ram - car si elle consomme trop de ram, elle occupe tout le cache - avant qu'elle ne provoque un plantage de X.

              Il y a des beaux graphiques sur
              http://www.mille-xterm.org/en/TerminalMemoryUsage

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

              • [^] # Re: Chromium est bien plus lent que Firefox

                Posté par . Évalué à 1.

                >on constate que l'application bouffe tout le cache disponible, ce qui provoque à tous les coups un plantage de X.

                J'avais bien compris, mais quand le noyau Linux détecte que la mémoire est trop utilisé, il ne plante pas: il sort sa boule de cristal, sélectionne l'application "responsable" et la tue.

                X devrait adopter un comportement similaire je pense..

Suivre le flux des commentaires

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