Journal Réflexion d'un utilisateur de Firefox avec un processeur Intel en 2019

23
25
mai
2019

Bonjour nal,

Je ne peux m'empêcher de mettre en parallèle les gains ahurissants de performance de Firefox depuis un an (cf la dernière dépêche en date) avec la dégradation tout aussi ahurissante des performances Intel depuis un an.

Tandis que les développements du premier sont entièrement tendus vers les moyens d'accroître la vitesse et la réactivité du logiciel (en même temps que sa sécurité et de proposer des outils de défense de la vie privée aux utilisateurs), le deuxième ne cesse de tenter de réparer les failles béantes de sécurité causées par ses choix bon marché d'optimisation de performance sur ses processeurs actuellement en circulation.

Du coup, en tant qu'utilisateur de Firefox ET d'un processeur Intel, je me demande si les gains de performance de Firefox suffiront à contrebalancer les dégradations de performance de mon processeur en 2019 (voyez les résultats pour un processeur Intel Core i7 3700K/3770K de même génération « Ivy Bridge » que le mien sur ces tests menés par Phoronix [1]).

Drôle d'époque.


[1] Pour comprendre le test :

Tests were done on Ubuntu 19.04 with the Linux 5.0 kernel while toggling the mitigation levels of off (no coverage) / auto (the default / out-of-the-box mitigations used on all major Linux distributions for the default protections) / auto,nosmt (the more restricted level that also disables SMT / Hyper Threading). The AMD CPUs were tested with off/auto as in the "auto,nosmt" mode it doesn't disable any SMT as it doesn't deem it insecure on AMD platforms.

Quand je lis par exemple :

The Core i7 3770K Ivybridge system took 2.3x longer to run this test under the complete mitigations or 1.6x the time if just using the default mitigations

[The i7 3770K] saw around a 14% hit to the default mitigated performance as well but that extended to 18~19% if disabling Hyper Threading in the name of security

Je me dis 1°) que c'est pas gagné 2°) que le mérite des uns (Mozilla) et l'incompétence des autres (Intel) n'est pas assez soulignée.

  • # Nuance

    Posté par . Évalué à 10 (+12/-2).

    Juste pour quand même nuancer, le genre de problèmes qui affectent les processeurs Intels, ils sont potentiellement aussi présents en grand nombres dans les logiciels qui sont comparables en terme de complexité. Ça a moins de conséquences évidemment parce qu’il y a plus de souplesses pour corriger et c’est évidemment plus facile de déployer du logiciel que de remplacer des microprocesseurs.

    Mais certes si il y a des erreurs de faites côté Intel, c’est quand même un peu fort de déclarer les uns compétents et les autres incompétents parce qu’il y a des erreurs de faites. Il y a aussi des erreurs chez Mozilla … C’est juste que ça fait moins mal quand les extensions sont désactivées pendant un week-end et qu’on a plus de chances d’oublier rapidement …

    Mais ça reste compliqué pour moi d’imaginer un monde ou un composant d’une complexité comme un processeur soit exempt de bug, même avec l’équipe la plus compétente du monde. Ou alors ce serait au détriment d’autres aspects, probablement.

    • [^] # Re: Nuance

      Posté par . Évalué à 4 (+3/-1).

      J'avoue que :

      […]ses choix bon marché d'optimisation de performance[…]

      Sans plus d'arguments ça me paraît osé.

      Sinon je ne crois pas que Firefox soit CPU bound. Si mon intuition est vrai tu va pouvoir dormir tranquillement sur ton manichéisme :)

      • [^] # Re: Nuance

        Posté par . Évalué à 5 (+3/-0).

        J'avoue que :

        […]ses choix bon marché d'optimisation de performance[…]

        Sans plus d'arguments ça me paraît osé.

        Depuis le lancement de l'HyperThreading des craintes ont été émises sur la sécurité, il me semble que c'est quasiment pareil avec le mécanisme d'exécution spéculative.
        Intel avait dix ans pour corriger leur implémentation du SMT.
        D'ailleurs leur dernière génération n'est pas concernée par Zombieload, comme si ils étaient au courant depuis un moment et qu'enfin ils se sont décidé à agir après le fiasco Meltdown et Foreshadow.

        En attendant, AMD va lancer sa troisième génération de processeurs Ryzen d'ici quelques mois. Il y aura de bonnes affaires dans le matériel d'occasion.

        • [^] # Re: Nuance

          Posté par . Évalué à 5 (+3/-0).

          Des gens qui crient au loup, il y en a tout le temps. Est-ce qu'il y a eu des démonstrations avant l'an dernier ? Si les gars en 10 ans n'avaient pas plus d'arguments que "ça paraît louche", c'est que tout ce dont on parle n'est pas si triviale que ça. Sinon je peux annoncer que SHA-3 est très louche à mon avis d'un point de vue sécurité et quand il commencera à s'effriter, dire que je l'avais bien dit.

          • [^] # Re: Nuance

            Posté par (page perso) . Évalué à 3 (+3/-2).

            Dans le cas d'Intel et Meltdown (Spectre était plus subtil) le risque potentiel devait être à mon avis assez évident pour Intel : aller spéculativement chercher des choses en mémoire (et donc modifier le cache avec) avant de faire le test vérifiant que le processus peut accéder à cette mémoire, ça « paraît risqué », quoiqu'on pense de cette formule :-) C'est le genre d'optimisation tordue dont les conséquences sont floues : ils ont parié et perdu.

            Pour les failles utilisant le SMT, pareil : optimisations tordues. OpenBSD trouvait ça suffisamment louche pour avoir désactivé ça il y a un an, l'histoire leur a donné raison bien vite. Pas étonnant, car la méfiance s'étant installée, plus de monde cherche les failles.

          • [^] # Re: Nuance

            Posté par . Évalué à 0 (+0/-2).

            Et encore, même si il y a des exploits qui traînent, c’est quoi la probabilité que les failles soient exploitables dans de vraies attaques ?

            Ça reste sans doute un outil dans l’arsenal du pirate, pas dit qu’en vrai il ait l’occasion sérieuse de l’utiliser un jour (je précise que j’ai absolument aucune idée de la situation dans le cas de ces failles précisément). Il doit falloir quand même des conditions assez compliquées à atteindre avant d’être en capacité d’exploiter de telles failles et de réussir.

            • [^] # Re: Nuance

              Posté par (page perso) . Évalué à 10 (+10/-1).

              Spectre était pas totalement évident à exploiter et le leakage d'information se faisait à moindre vitesse (moins de 50K/s de mémoire) et c'est pourquoi il a suscité moins de réactions. Meltdown était exploitable avec autour de 500K/s de fuite d'information par n'importe quel utilisateur d'un système en exécutant un programme pas trop long (sans les patchs dans les navigateurs pour réduire la précision des timers, c'était exploitable depuis javascript, probablement à moindre vitesse) — c'est bien pour cela que ça a enragé autant de monde et que les OS ont mis en place des patchs rapidement malgré la perte importante de performances et donc le coût de ces patchs. Notons que les chiffres que je donne, c'était avec les premiers prototypes pour exploiter la faille, il se peut que des gens aient réussi à faire mieux depuis.

              Si tu veux voire des exemples, le site officiel de Meltdown a quelques vidéos, comme celle-ci.

              • [^] # Re: Nuance

                Posté par (page perso) . Évalué à 3 (+2/-1).

                c'était exploitable depuis javascript, probablement à moindre vitesse

                Maintenant que j'y pense, ce point n'est de mémoire pas correct : en ce qui concerne Meltdown, depuis javascript, c'est plus compliqué que ça : les proofs of concept javascript que j'ai vus sont pour Spectre. Meltdown est facile à exploiter depuis du code compilé uniquement, donc impacte surtout les systèmes multi-utilisateur où il est facile d'exécuter son propre binaire ; après, javascript/wasm utilisent un JIT : peut-être qu'il y a moyen quand même d'écrire du javascript/wasm qui compile vers ce qu'il faut, mais c'est moins évident a priori, en tous cas je ne vois perso pas à quoi ça ressemblerait.

      • [^] # Re: Nuance

        Posté par . Évalué à 0 (+2/-2).

        J'ajouterais que les failles récentes dont on parle (spectre, meltdown, etc) ne sont pas spécifiques aux processeurs Intel, mais à tous les processeurs exploitant une architecture superscalaire et ayant recours aux branchements spéculatifs. Cela inclut entre-autres Intel, AMD, mais aussi certains CPU ARM par exemple…

        Après le bench que tu cites démontre simplement que si Intel est le plus impacté en termes de perfs pures, c'est surtout dû au fait que Intel avait poussé plus loin que AMD les optimisations sur le branchement spéculatif, et que la perte de cet "avance" remet les 2 fondeurs sur un pied d'égalité sur le sujet de l'écart de perfs !

        • [^] # Re: Nuance

          Posté par (page perso) . Évalué à 6 (+5/-1).

          Meltdown est spécifique à Intel. Il me semble que certains problèmes récents du SMT (ZombieLoad) ne concernent que Intel également. AMD a son lot de bugs également, ceci dit, il semble juste que pour la spéculation ils aient été un peu plus raisonnables, mais l'histoire nous dira.

          Spectre est plus général et affecte en effet la plupart des archis (pas toutes).

          • [^] # Re: Nuance

            Posté par . Évalué à 3 (+1/-0).

            Meltdown est spécifique à Intel. Il me semble que certains problèmes récents du SMT (ZombieLoad) ne concernent que Intel également.

            Même chose pour Foreshadow, que j'ai cité dans mon précédent message, qui est une vulnérabilité dans l'implémentation du jeu d'instruction SGX propre aux CPU Intel de génération Skylake et suivantes.

            • [^] # Re: Nuance

              Posté par (page perso) . Évalué à 3 (+2/-1).

              Une vulnérabilité dans un jeu d'instructions dédié à la sécurité, c'est moche :(

              La connaissance libre : https://zestedesavoir.com

              • [^] # Re: Nuance

                Posté par . Évalué à 2 (+0/-0).

                Pire, trois vulnérabilités : une par an.

  • # Autre(s) facteur(s)

    Posté par . Évalué à 5 (+10/-5). Dernière modification le 26/05/19 à 01:00.

    Un navigateur est une telle usine à gaz qu'il me semble difficile de mesurer leur performances.
    D'autant plus qu'il y a des facteurs externe pas évident à prendre en compte.

    Exemple : Google.
    Google et Mozilla ont longtemps collaboré.
    Jusqu'à ce que Google développe Chrome.
    Et là, bizarrement, Firefox a vu ses perfs baisser sur les sites Google.
    Un des coups de p… Phourbe … Dont je me rappelle à peu près bien, ça a été de placer une frame invisible devant les vidéos de YouTube. Je parle de Google, qui possède YouTube, et qui bricole le "site web" YouTube pour ajouter cette frame.
    Chrome, évidemment, a tout de suite géré cette transparence. Aidé par le hardware probablement.
    Firefox, lui, s'est mis à ramer sévère. Sur YouTube.
    Après, c'est la course à l'échalote. Firefox a fini par rattraper ce retard. Puis le suivant. Puis le suivant …

    Autre exemple, encore une fois très détaché de Mozilla : sur mon MacBook Pro (Late 2013), Firefox a commencé à ramer de la mort qui tue vers février/mars de cette année.
    Première piste : ça avait peut-être quelque chose à voir avec les 350 ou 400 onglets ouverts … Mais …
    Seconde piste : c'est la période à laquelle je me suis décidé à passer à Mojave, la dernière version de macOS. Mouais, j'ai l'impression que Tim voudrait que je change mon Mac … Ou que j'utilise Safari …
    Des clous !
    Tiens, au passage, depuis quelques mois, PathFinder voudrait que j'upgrade aussi ($20 pour la version 8). Bizarre, depuis ce moment, il devient périodiquement super lent. Vérification faite, c'est normal, quand on consomme presque 100% des 16 Go de RAM ! Prend moi pour une buse, une fuite mémoire, jamais vue jusque là ?…

    Mais je sens que je commence à m'égarer … Qui a dit comme d'hab ?!?!

    Pour le premier exemple, voilà l'idée que se fait Google de la concurrence libre et non faussée … Votez bien tout à l'heure !

  • # Skylake ralentit Internet

    Posté par . Évalué à 4 (+3/-0).

  • # Mauvaise foi ?

    Posté par (page perso) . Évalué à 1 (+4/-5).

    Je me dis 1°) que c'est pas gagné 2°) que le mérite des uns (Mozilla) et l'incompétence des autres (Intel) n'est pas assez soulignée.

    <avocat du diable>
    En même temps, si le navigateur Mozilla avait pas été codé avec les pieds pendant des années, ils (Mozilla) ne parviendraient pas à un tel gain de perf …
    </avocat du diable>

    • [^] # Re: Mauvaise foi ?

      Posté par (page perso) . Évalué à 3 (+3/-2).

      spafo :)

    • [^] # Re: Mauvaise foi ?

      Posté par . Évalué à 10 (+10/-0). Dernière modification le 27/05/19 à 11:09.

      Pendant ce temps là, ça fait des années que Chrome se goinfre de RAM et personne ne se plaint de ce problème de perfs. Les memory leaks de Firefox eux sont corrigés depuis des années.

      Il y a effectivement une part de mauvaise foi dans ces histoires de perfs de Firefox, en défaveur de Firefox et inversement en faveur de Chrome.

    • [^] # Au pied de la lettre

      Posté par . Évalué à 10 (+10/-1). Dernière modification le 27/05/19 à 12:30.

      si le navigateur Mozilla avait pas été codé avec les pieds pendant des années

      Pour prendre le contre-pied, ce que tu écris est bête comme tes pieds ! Mozilla est parti du bon pied et ils ont mis Google au pied du mur tandis que IE est en train de partir les pieds devant. Ils (Mozilla) se sont peut être pris les pieds dans le tapis à un moment mais ils se sont bien remis sur pied tout en gardant les pieds sur terre et, aujourd'hui, Chrome et Firefox sont sur un pied d'égalité. Grace à eux, nous sommes en mesure de trouver chaussure à notre pied et ça, c'est le pied !

      • [^] # Re: Au pied de la lettre

        Posté par (page perso) . Évalué à 5 (+3/-0).

        Pour prendre le contre-pied, ce que tu écris est bête comme tes pieds ! Mozilla est parti du bon pied et ils ont mis Google au pied du mur tandis que IE est en train de partir les pieds devant. Ils (Mozilla) se sont peut être pris les pieds dans le tapis à un moment mais ils se sont bien remis sur pied tout en gardant les pieds sur terre et, aujourd'hui, Chrome et Firefox sont sur un pied d'égalité. Grace à eux, nous sommes en mesure de trouver chaussure à notre pied et ça, c'est le pied !

        Dans cette prose, très foot-fetish, il y a peu d'éléments concrets….

        De mon côté, concrétement, ce que j'ai vu, c'est que certes Chrome se goinfre de RAM, mais se sort beaucoup mieux des situations ou il en "prend trop"…
        Le Firefox de ma Debian (60.6.1esr (64-bit)) ne sait juste pas s'arrêter. Il consomme, consomme jusqu'à rendre le système totalement inutilisable avec, comme seule issue, l'intervention de l'OOM-Killer après 30 minutes de moulinage inutile ou … le reboot.
        Peut être que la différence entre Chromium et Firefox se limite à:

        if ( (buff = malloc(buff, 4096)) == NULL ) {
           coupez_l_eau();
        }

        Mais toujours est il que rien que ce petit if suffit à faire la différence …

        D'ailleurs, si Mozilla avait mis Google "au pied du mur", on ne verrait pas autant de chromium sur les linux….

        Je continue à faire de la resistance et à ne pas utiliser Chromium…
        Même si ça s'est amélioré avec le temps, je suis désolé, mais Chromium reste bien meilleur sur des machines qui remplisse la condition ( RAM < 32 GiB && Onglets ouverts > 10 )

        • [^] # Re: Au pied de la lettre

          Posté par . Évalué à 6 (+4/-0).

          Peut être que la différence entre Chromium et Firefox se limite à

          C'est un peu plus compliqué que ça :

          By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer.

          (cf: https://linux.die.net/man/3/malloc)

          • [^] # Re: Au pied de la lettre

            Posté par (page perso) . Évalué à 2 (+1/-1).

            Tu me parles de Linux, mais je te parle de Firefox et Chromium tout deux sur plateforme Linux
            Donc pourquoi Chromium s'en sort mieux ?

            • [^] # Re: Au pied de la lettre

              Posté par . Évalué à 2 (+0/-0).

              Je n'en sait rien je dis juste que c'est pas juste la gestion du retour du malloc(3)

            • [^] # Re: Au pied de la lettre

              Posté par . Évalué à 2 (+0/-0).

              Ce qu’il te dit c’est que le bout de code que tu as écris, Linux ne retournera jamais NULL… donc ce n’est pas la bonne façon de savoir si on peut allouer. De toute façon, tant qu’il y a du swap, tu peux allouer.

              La bonne solution c’est les limitation cgroup.

              • [^] # Re: Au pied de la lettre

                Posté par (page perso) . Évalué à 3 (+1/-0).

                J'entend, mais il ne faut pas prendre mon exemple "naif" au pied de la lettre.
                Les faits sont là: sur du site gourmand (type "Top 10 des ") avec du JS dans tout les sens et de la régie publicitaire aggressive, Firefox finit inexorablement par consommer trop de mémoire, rendant par la même occasion le système instable voir totalement inutilisable.
                Dans le même contexte, Chromium n'a pas se comportement: il aura tendance à planter tout seul dans sons coin.

                Donc je suis d'accord avec le fait qu'il existe de workaround système pour limiter la casse, mais la question demeure: pourquoi et comment Chromium s'en tire mieux sur ce type de problème ?

                • [^] # Re: Au pied de la lettre

                  Posté par . Évalué à 3 (+1/-0).

                  Donc je suis d'accord avec le fait qu'il existe de workaround système pour limiter la casse, mais la question demeure: pourquoi et comment Chromium s'en tire mieux sur ce type de problème ?

                  J'en sait rien, j'ai juste donné une information.

                • [^] # Re: Au pied de la lettre

                  Posté par (page perso) . Évalué à 5 (+4/-1). Dernière modification le 29/05/19 à 22:03.

                  Les faits sont là: sur du site gourmand (type "Top 10 des ") avec du JS dans tout les sens et de la régie publicitaire aggressive, Firefox finit inexorablement par consommer trop de mémoire, rendant par la même occasion le système instable voir totalement inutilisable.
                  Dans le même contexte, Chromium n'a pas se comportement: il aura tendance à planter tout seul dans sons coin.

                  Chez moi c'est l'inverse : Chrome bouffe toute la mémoire très rapidement, alors que Firefox ne m'oblige à relancer la machine qu'environ une fois par mois (avant je n'étais jamais obligé de redémarrer, depuis quelques mois même fermer la session ne libère pas toute la mémoire).

                • [^] # Re: Au pied de la lettre

                  Posté par (page perso) . Évalué à -1 (+3/-6).

                  pourquoi et comment Chromium s'en tire mieux sur ce type de problème ?

                  Vu que j'utilise Firefox en le laissant ouvert des jours / semaines / (nan pas des mois faut quand même reboot pour les màj) avec au moins autant d'onglets que tu décris, sans avoir de soucis, je me permets une hypothèse

                  Le Firefox de ma Debian

                  Quand on utilise une distrib obsolète dont les développeurs se croient meilleurs que les autres et patchent tout ce qui passe, quitte à générer des certificats SSL déterministes par exemple, et qu'on a un souci que n'ont pas les autres, peut-être qu'il faut creuser par là ?

                  • [^] # Re: Au pied de la lettre

                    Posté par . Évalué à 3 (+2/-1).

                    OK, et quand ça me fait la même chose que ce qu'il décrit sur une Arch avec un Firefox à jour ?
                    C'est simple, je suis maintenant obligé de fermer Firefox (& Thunderbird) tous les soirs pour ne pas risquer de retrouver ma machine figée, RAM & SWAP pleines, CPU à 100%.

                    Alors moi aussi je fais de la résistance, je reste sous FF, j'aime mon workflow et mes extensions, mais franchement ça me démange de passer sous Chromium. Si Chromium gérait Firefox Sync je pense que ça serait déjà fait.

                    • [^] # Re: Au pied de la lettre

                      Posté par . Évalué à 4 (+2/-0).

                      Tu as regardé en fin de journée quels onglets consomment le plus de ressources ? Ça te permettrait de le fermer ou de le décharger. Je sais que j'ai eu des problèmes avec l'une des pages de Jenkins par exemple.

                      Après ta machine qui n'arrive pas à sortir de la veille le matin c'est surprenant que ce soit de la faute à Firefox

                      • [^] # Re: Au pied de la lettre

                        Posté par . Évalué à 10 (+10/-1).

                        Tu as regardé en fin de journée quels onglets consomment le plus de ressources ? Ça te permettrait de le fermer ou de le décharger. Je sais que j'ai eu des problèmes avec l'une des pages de Jenkins par exemple.

                        De manière générale ça ne rime pas à grand chose de comparer des navigateurs Web si on ne se met pas d'accord sur les pages Web consultées.

                        Je n'y connais rien en technologies Web, mais j'ai l'impression qu'il y a des différences énormes entre les pages Web. Entre par exemple LinuxFr, sur lequel naviguer, faire défiler, interragir, donne l'impression de travailler avec une feuille de papier : c'est léger, c'est mobile c'est fluide, c'est facile d'écrire dessus.

                        Et puis il y a des sites qui donnent l'impression d'être des plaques d'acier, pour lesquels il faut du matériel puissant si on veut simplement les faire défiler ou écrire quelque chose dessus.
                        Des sites de merde qui réagissent si on les fait défiler, ou juste si on passe la souris au-dessus d'un élément, ce que je trouve intrusif au possible : pour moi, la souris ne doit avoir aucun effet tant que je ne presse pas un bouton. Sinon ça donne l'impression d'avoir un stylo qui coule : pour agir sur une zone en venant d'une autre, je dois faire ultra attention aux zones que je traverse.
                        Des sites épais, avec des couches de pop-up, des couches transparentes qui empêchent le clic droit sur les images, des couches successives de code javascript (du code qui appelle une bibliothèque depuis un autre site et s'en sert pour traiter des données venant d'un CDN).

                        Je pense que "protéger les utilisateurs" sur Internet devrait passer par des limitations techniques à la lourdeur et aux capacités des sites Web. Il y a des contrôles qui devraient rester souverains, comme fermer une page Web, accéder forcément aux menus d'une image ou d'une vidéo en y faisant un clic droit, survoler des éléments à la souris sans modifier l'aspect du site, sélectionner du texte et avoir accès à son menu contextuel. Et l' "épaisseur" (le rapport entre la surface affichée à l'écran et le volume total de données à traiter) des sites devrait avoir une limite, afin de limiter la puissance de calcul nécessaire : pas plus de tant de calculs par seconde, par pixel de site Web.

                        Chaque fois que j'ai Firefox qui mouline et galère, je commence par me demander : est-ce que le site Web n'abuse pas trop ? Toujours la réponse est "oui". Je comprends bien qu'on fasse la course à la puissance et qu'on se fasse des compromis de principe (sur la vie privée, la confidentialité..) pour prendre la voiture Google qui fait 300 chevaux au lieu de la voiture Mozilla avec son petit moteur de 70 chevaux. Mais personnellement je préfère me demander : Est-ce qu'on a vraiment besoin d'une remorque d'une tonne pour aller chercher le pain en voiture ?
                        Est-ce normal de charger du code de dizaines de sources différentes et de construire en local un rendu complexe uniquement à partir de données distantes et de règles de plus en plus nombreuses d'interprétation de ces données, juste pour faire quelque chose qu'on savait faire sans navigateur Web dans les années 90 : échanger des messages, lire des mails ou consulter les informations.

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

                        • [^] # Re: Au pied de la lettre

                          Posté par . Évalué à 4 (+2/-0).

                          Les pages ouvertes sont clairement responsables. Slack, Jenkins, la famille Atlassian, sans compter certains sites d'informations débordants de pub. Mais le problème c'est que Firefox ne se limite pas. Si un site/script demande toute la RAM, bin il la lui donne… Sans compter les erreurs du style Unresponsive script "chrome://messenger/content/folderPane.js:503" qui font monter le processeur à 100% , sans possibilité de reprendre la main (c'est moins fréquent mais tout aussi bloquant).

                          • [^] # Re: Au pied de la lettre

                            Posté par . Évalué à 2 (+1/-1).

                            Mon point c'est que même si ça montre des problèmes chez Firefox.

                            1. il est possible de reporter les sites à problèmes
                            2. il est possible d'avoir des mesures d'évitement : décharger les onglets en question, les couper, désactiver le js tout ou partiellement sur ses sites, les lancer dans des instances spécifiques de Firefox potentiellement dans des cgroup différents. On est content de nos outils entre autre pour ça. Si ça nous pose des problèmes, on peut agir et y faire quelque chose. C'est pas parfait, mais c'est ça la voie du geek.

                            Personnellement il faudrait que je remonte le problème que j'ai constaté. C'est la page de Jenkins qui affiche les builds en pipeline. Si je la garde ouverte des heures avec un build toutes les 20 minutes, elle consomme beaucoup de ressources. Je présume que les manipulations du DOM que fait Jenkins crée une fuite mémoire sur Firefox (aucune idée de si ça marche bien chez la concurrence), mais je ne suis pas allé plus loin.

                            • [^] # Re: Au pied de la lettre

                              Posté par . Évalué à 4 (+2/-0). Dernière modification le 01/06/19 à 03:11.

                              c'est ça la voie du geek.

                              Et comme j'en fais partie depuis… longtemps, j'ai déjà pratiqué quasiment tout ce que tu as proposé sauf les cgroups. Déjà j'utilise 3 profils différents de FF selon l'activité, j'ai autotab-discard qui décharge les onglets non utilisés depuis 10 minutes, je n'ouvre certains sites que dans Chromium, etc…
                              Et comme j'ai mis en place ces rustines j'arrive à conserver ma routine et mon butineur favori. Mais avoue que c'est chiant… Je n'imaginais pas en passant sous Arch il y a 10 ans que mon plus gros (seul ?) soucis de stabilité serait mon navigateur. D'ailleurs en ces temps béni je n'avais aucun soucis avec Firefox !

                              • [^] # Re: Au pied de la lettre

                                Posté par . Évalué à 3 (+1/-0).

                                C'est très très très bizarre. Soit on est beaucoup à avoir beaucoup de chance, soit il y a un problème avec ton utilisation (je ne suis pas que ton utilisation est mauvaise, mais que tu fais des choses ou visite des sites qui font planter ton Firefox) ou ton installation (peut-être que le Firefox d'aujourd'hui est is sensible à une bibliothèque qui ne lui convient pas).

                                Évidemment, à ta place, j'aurais tendance à investiguer ce qui peut être réglé de ton côté. Si tu ne trouves pas de site qui pose problème, je regarderai au niveaux de ton profile et des extensions.

                                Mon point n'est pas d'incriminer toi plutôt que Firefox, juste d'essayer de comprendre d'où ça vient. Au contraire ça montre un problème dans Firefox de résilience, mais qui devrait être évitable.

                                J'imagine que Firefox est plus lent (ou plus consommateur de ressources) que la concurrence, qu'il n'a plus beaucoup de part de marché mais s'il en était au point que tu décrit, il n'existerait plus.

        • [^] # Re: Au pied de la lettre

          Posté par (page perso) . Évalué à 1 (+0/-0).

          Peut être en le lançant avec ulimit, genre :

          ulimit -d 2000000 && firefox

          ou avec -v (virtual memory size), voir les deux…

        • [^] # Re: Au pied de la lettre

          Posté par . Évalué à 4 (+3/-0).

          Dans cette prose, très foot-fetish, il y a peu d'éléments concrets…

          Il n'y a absolument aucun élément concret. J'admets bien volontiers que mon commentaire était inutile. J'ai été vexé de lire que Mozilla Firefox avait été codé avec les pieds des années. Si leur code a été écrit avec les pieds, qu'en est-il du mien ? Au mieux, je l'aurais écrit avec le front ou, de façon plus réaliste, avec le dos.

          https://archive.mozilla.org/pub/firefox/releases/1.0/source/

          Historiquement, Google a lancé Chrome en réponse à l'émergence de Firefox, 2 extraits (sortis de leur contexte) de Wikipedia :

          co-founders Sergey Brin and Larry Page hired several Mozilla Firefox developers and built a demonstration of Chrome

          rumors of Google building a web browser first appeared (…) shortly after the final 1.0 release of Mozilla Firefox, which was surging in popularity

          Cela vient justifier le "ils ont mis Google au pied du mur" en les "forçant" à rentrer dans les browser wars (que Google remporte haut la main).

          Dans tous les cas, je te remercie d'avoir élevé la discussion qui volait au ras du sol.

          • [^] # Re: Au pied de la lettre

            Posté par (page perso) . Évalué à 3 (+1/-0).

            Il n'y a absolument aucun élément concret. J'admets bien volontiers que mon commentaire était inutile. J'ai été vexé de lire que Mozilla Firefox avait été codé avec les pieds des années. Si leur code a été écrit avec les pieds, qu'en est-il du mien ? Au mieux, je l'aurais écrit avec le front ou, de façon plus réaliste, avec le dos.

            Et désolé si je t'ai vexé, en particulier si tu es contributeur au projet.
            J'ai volontairement un peu forcé le trait car l'auteur du journal l'avait fait dans l'autre sens… et de façon assez peu objective au final.
            Bien que libriste, utilisateur quotidien de GNU/Linux et son écosystème (en particulier Firefox), j'ai toujours du mal avec le manque d'objectivité ;-)

            Firefox reste un excellent produit, surtout venant d'une communauté de développeur pour beaucoup bénévoles.

            Cela vient justifier le "ils ont mis Google au pied du mur" en les "forçant" à rentrer dans les browser wars (que Google remporte haut la main).

            Ok, ce contexte est le bienvenue :)

            Dans tous les cas, je te remercie d'avoir élevé la discussion qui volait au ras du sol.
            Pas de quoi ;-)

            • [^] # Re: Au pied de la lettre

              Posté par (page perso) . Évalué à 4 (+3/-1). Dernière modification le 28/05/19 à 14:48.

              J'assume la subjectivité d'un journal ;)

              Et je redis qu'Intel s'en sort honteusement bien dans cette affaire, étant donné qu'il vend ses processeurs au prix de leurs performances et qu'il y a donc préjudice pour ses clients dont moi.

  • # désactivez use smooth scrolling

    Posté par . Évalué à 1 (+3/-2).

    Mon seul manque après avoir goûté à Chrome, c'était la rapidité du scroll et je l'ai retrouvée sur Firefox en désactivant use smooth scrolling. A part ça, je n'ai rien à envier à Chrome.

  • # Linux 5.3 Could Finally See FSGSBASE - Performance Improvements Back To Ivybridge

    Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 17/06/19 à 23:58.

    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.3-FSGSBASE

    Je n'ai pas les compétences techniques pour savoir si c'est une bonne nouvelle ou si ça ouvre de nouvelles brèches pour compenser les pertes de performances lié au colmatage des anciennes brèches, ce qui pourrait être lassant à force ?

Envoyer un commentaire

Suivre le flux des commentaires

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