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
Journal Performance des navigateur web: linux parent pauvre ?
12
déc.
2009
# et m.... les fautes...
Posté par aurel (site web personnel, Mastodon) . Évalué à 8.
[^] # Re: et m.... les fautes...
Posté par aurel (site web personnel, Mastodon) . Évalué à 6.
[^] # Re: et m.... les fautes...
Posté par khivapia . Évalué à 10.
ç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 Zenitram (site web personnel) . Évalué à 0.
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 aurel (site web personnel, Mastodon) . Évalué à 10.
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 Zenitram (site web personnel) . Évalué à 4.
[^] # Re: Linux parent pauvre du fait de part de marché
Posté par imr . Évalué à 5.
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 pasBill pasGates . Évalué à 4.
- 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 Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 Nitchevo (site web personnel) . Évalué à 1.
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 claudex . Évalué à 6.
« 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 Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 bubar🦥 (Mastodon) . Évalué à 3.
/*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 Pinaraf . Évalué à 5.
Ça explique la différence de perf ?
[^] # Re: 32 vs 64 bits
Posté par Sphax . Évalué à 2.
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 aurel (site web personnel, Mastodon) . Évalué à 3.
Serait-ce un complot ?
[^] # Re: 32 vs 64 bits
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
[1] http://groups.google.com/group/mozilla.dev.tech.js-engine/br(...)
[^] # Re: 32 vs 64 bits
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
# avec le navigateur kazehakase
Posté par palm123 (site web personnel) . Évalué à 3.
ウィズコロナ
[^] # Re: avec le navigateur kazehakase
Posté par palm123 (site web personnel) . Évalué à 3.
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 2198.0ms +/- 5.8%
ウィズコロナ
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Firefox vs le reste du monde
Posté par aurel (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: Firefox vs le reste du monde
Posté par Frédérick Diot . Évalué à 2.
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 aurel (site web personnel, Mastodon) . Évalué à 5.
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 yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Firefox vs le reste du monde
Posté par suJeSelS . Évalué à 3.
[^] # Re: Firefox vs le reste du monde
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Firefox vs le reste du monde
Posté par suJeSelS . Évalué à 4.
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 yellowiscool . Évalué à 0.
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 Moonz . Évalué à 5.
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 suJeSelS . Évalué à 1.
# Dans le détail
Posté par Julien Gilbert . Évalué à 8.
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 aurel (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Dans le détail
Posté par yellowiscool . Évalué à 7.
--->[]
Envoyé depuis mon lapin.
[^] # Re: Dans le détail
Posté par tiot (site web personnel) . Évalué à 2.
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 NeoX . Évalué à 3.
# Buildconfig ?
Posté par Julien Humbert . Évalué à 3.
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 Antoine . Évalué à 2.
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 aurel (site web personnel, Mastodon) . Évalué à 2.
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 Antoine . Évalué à 3.
[^] # Re: Mandriva x86-64, Firefox 3.5 => ouch
Posté par thedidouille . Évalué à 2.
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: Mandriva x86-64, Firefox 3.5 => ouch
Posté par Antoine . Évalué à 2.
Je ne vais pas m'amuser à recompiler Firefox (pas fou), par contre sur mon netbook je crois que je vais installer un build officiel de la 3.5 voire de la 3.7.
[^] # Re: Buildconfig ?
Posté par Frédéric . Évalué à 2.
* 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 Antoine . Évalué à 2.
# uzbl et surf
Posté par barmic . Évalué à 2.
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 mr_pouit . Évalué à 0.
[^] # Re: uzbl et surf
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: uzbl et surf
Posté par barmic . Évalué à 3.
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 batman19 . Évalué à 1.
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 Psychofox (Mastodon) . Évalué à 4.
epiphany (en version gecko puis webkit)
konqueror
et éventuellement midori ou arora...
[^] # Re: et les autres
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
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 Psychofox (Mastodon) . Évalué à 5.
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 aurel (site web personnel, Mastodon) . Évalué à 6.
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 Grunt . Évalué à 6.
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 Zorro (site web personnel) . Évalué à 3.
# Et maintenant
Posté par Olivier (site web personnel) . Évalué à 2.
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 aurel (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Et maintenant
Posté par pascalc . Évalué à 6.
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 Pinaraf . Évalué à 2.
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 pascalc . Évalué à 4.
[^] # Re: Et maintenant
Posté par Pinaraf . Évalué à 1.
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 pascalc . Évalué à 1.
[^] # Re: Et maintenant
Posté par Pinaraf . Évalué à 2.
[^] # Re: Et maintenant
Posté par nomorepost . Évalué à 2.
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 pascalc . Évalué à 2.
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 Antoine . Évalué à 2.
[^] # Re: Et maintenant
Posté par pascalc . Évalué à 3.
Pour l'icône, bah j'utilise une icône Firefox (dossier icons dans le tar.gz).
[^] # Re: Et maintenant
Posté par Olivier (site web personnel) . Évalué à 1.
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 pascalc . Évalué à 1.
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 Zorro (site web personnel) . Évalué à 1.
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 pascalc . Évalué à 4.
[^] # Re: Et maintenant
Posté par Zorro (site web personnel) . Évalué à 0.
[^] # Re: Et maintenant
Posté par briaeros007 . Évalué à 1.
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 pascalc . Évalué à 4.
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 briaeros007 . Évalué à 2.
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 pascalc . Évalué à 3.
[^] # Re: Et maintenant
Posté par briaeros007 . Évalué à 0.
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 Littleboy . Évalué à 1.
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 briaeros007 . Évalué à 3.
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 Littleboy . Évalué à 1.
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 briaeros007 . Évalué à 2.
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 Zorro (site web personnel) . Évalué à 3.
[^] # Re: Et maintenant
Posté par Zorro (site web personnel) . Évalué à 2.
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 Julien Humbert . Évalué à 1.
[^] # Re: Et maintenant
Posté par Littleboy . Évalué à 3.
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 boq . Évalué à 4.
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 aurel (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: moi aussi! moi aussi!
Posté par Littleboy . Évalué à 3.
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 tgl . Évalué à 1.
> 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 tgl . Évalué à 4.
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 tgl . Évalué à 8.
> 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 pascalc . Évalué à 2.
Il faut que tu demandes une review sur ton patch maintenant :)
[^] # Re: Qlqs résultats sunspider sur x86_64
Posté par tgl . Évalué à 2.
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 pascalc . Évalué à 2.
[^] # Re: Qlqs résultats sunspider sur x86_64
Posté par Fabimaru (site web personnel) . Évalué à 2.
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 Axioplase ıɥs∀ (site web personnel) . Évalué à 5.
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 Laurent J (site web personnel, Mastodon) . Évalué à 10.
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 aurel (site web personnel, Mastodon) . Évalué à 4.
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 zebra3 . Évalué à 4.
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 pascalc . Évalué à 4.
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 Bruno Ethvignot (site web personnel) . Évalué à 2.
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 Antoine . Évalué à 2.
Sauf erreur de ma part, c'est désactivable (cf. « PRAGMA synchronous »).
# Arch
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.