Au moment de la sortie de Firefox 4 beta j'avais eu un peu de temps pour tester les performances javascript de cette nouvelle version et les comparer avec les versions stables de Firefox et de Chrome.
Benoit Jacob avait alors posté une réponse indiquant que tout le travail d'optimisation sur le javascript n'avait pas encore été intégré et qu'un test des performances de la beta n'avait pas beaucoup de sens.
15 jours plus tard (aujourd'hui donc) j'ai encore une petite heure devant moi, je ne suis pas trop motivé pour faire avancer la news du noyau 2.6.36 et j'ai donc décidé de refaire le test.
Évidemment cette fois je vais utiliser la nightly build de Firefox qui intègre les optimisations javascript. Pour les férus de technique ces optimisations sont liées au nouveau moteur JaegerMonkey qui complète le moteur existant TraceMonkey.
Sans plus attendre tournons nous vers les résultats du comparatif.
Hardware:
- ThinkPad T400
- Intel Core 2 Duo 2.26 GHz
- 2 Go de RAM
Versions des logiciels:
- Firefox 3.6.9 (version stable)
- Firefox 4 b6pre (version nightly build)
- Chrome 6.0.472.55 (version stable)
- Chrome 7.0.517 (version de dev)
Benchmarks:
- SunSpider => http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
- V8 Benchmark v5 (attention ce bench est d'origine Google) => http://v8.googlecode.com/svn/data/benchmarks/v5/run.html
- Dromaeo Javascript (attention ce bench est d'origine Mozilla) => http://dromaeo.com/?dromaeo
Résultats:
SunSpider Firefox 3.6.9 (version stable) => 2192.6 ms
SunSpider Firefox 4 b6pre (version nightly build) => 1281.6 ms
SunSpider Chrome 6.0.472.55 (version stable) => 549.1 ms
SunSpider Chrome 7.0.503 (version de dev) => 699.2 ms
V8 Firefox 3.6.9 (version stable) => 496 points
V8 Firefox 4 b6pre (version nightly build) => 2164 points
V8 Chrome 6.0.472.55 (version stable) => 5117 points
V8 Chrome 7.0.503 (version de dev) => 4542 points
Dromaeo Firefox 3.6.9 (version stable) => 91.73 runs/s
Dromaeo Firefox 4 b6pre (version nightly build) => 322.92 runs/s
Dromaeo Chrome 6.0.472.55 (version stable) => 497.27 runs/s
Dromaeo Chrome 7.0.503 (version de dev) => 476.79 runs/s
Interprétation:
- L'écart de performances est considérable entre la version actuelle de Firefox et la future version 4. Joli progrès !
- Cette nighty Build est vraiment plus performante que la beta testée il y a 15 jours sur le bench V8 de Google (sur les 2 autres tests c'est moins probant).
- La version de développement de Chrome a des performances légèrement inférieures à la version stable.
- Chrome reste loin devant Firefox (du moins en ce qui concerne la rapidité de traitement du javascript).
Journal Comparons les performances Javascript de Firefox et Chrome
13
sept.
2010
# dev
Posté par CrEv (site web personnel) . Évalué à 10.
souvent les versions de dev sont buildés avec des options de debug, qui ralentissent l'exécution
[^] # Re: dev
Posté par El Titi . Évalué à 1.
C'est juste qu'ils ont mis quelques boucles dans le vide pour ne pas trop humilier la concurrence.
Mais on attend Chrome sur le support de l'accélération matérielle
http://www.pcinpact.com/actu/news/59212-firefox-4-beta-5-nou(...)
Ouppps pardon !
[^] # Re: dev
Posté par manatlan (site web personnel) . Évalué à 4.
Souvent (pour ne pas dire tout le temps), mozilla fait les annonces en premier ... Mais, c'est clairement chrome/chromium qui sort avant, avec le résultat et qui marche.
C'était le cas pour les premiers gros support html5, la balise video, la synchro des bm/extensions, etc ...
Je ne serai vraiment pas surpris, qu'on ait un chrome/chromium utilisant l'acceleration hardware avant une première release de FF4 ;-)
[^] # Re: dev
Posté par bubar🦥 (Mastodon) . Évalué à 9.
Premier exemple qui me vient en tête, là :
Essayes d'utiliser Chrome pour valider ta connection à FreeWifi : il n'y arrive pas, se vautre comme une bouse, et n'affiche jamais la page de connection. Supaire. Et au passage, la différence entre Chrome et Chromium, un exemple permettant de dire que Chromium ne sert à rien (si c'est pour avoir le même fonctionnement que Chrome, non merci) bref chromium c'est juste une recompilation de chrome (et moi qui croyais que certaines briques étaient virées, pas seulement celles pas libres éventuellement par rapport à chrome mais aussi celles qui concerne la vie privée). A un expert du code de Chromium de nous expliquer pourquoi le packaging dans les distro fait qu'on se retrouve en fait avec le même truc ...
Lance Firefox, paf il comprend aussitôt ce qu'il se passe. D'ailleurs il réagit aussi illico à un changement système (genre un truc con d'utilisateur con : j'appuie sur la touche de coupure du wifi, firefox le voit illico quant chromium/chrome va ramer pendant 20 secondes avant de comprendre qu'il est hors ligne)
Bref en plus des comparatifs purs, il y aussi la qualité d'intégration au système (oula je sens que certains vont hurler, je veux juste parler "à l'utilisation").
Dommage que Firefox 4 ne soit pas utilisable sur gnu/linux, sinon je l'utiliserai ! (ai vu celui de monde frère sous windows : ouhaou !!) A la question "pourquoi pas utilisable" je répond par une autre question : pourquoi "firefox 4 beta execmemstack ?" moi je veux bien mettre un # devant user - core 0 pour mon utilisateur standard, sûr ça va m'aider à avoir des infos, okok, mais ça ne change rien directement, il me faudrait ensuite mettre en place une règle permissive spécialement pour lui, zut..."
[^] # Re: dev
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: dev
Posté par bubar🦥 (Mastodon) . Évalué à 8.
Avec SElinux activé, firefox 4 tel qu'il est livré (binaire) se fait envoyer bouler par SElinux pour cause de execmemstack. Alors bien sûr c'est de la faute à mon système, jaikapautilizé2truc2sécurité :)
[^] # Re: dev
Posté par pascalc . Évalué à 3.
Qu'est-ce que c'est que cette histoire de pas utilisable sous Linux ? Ca marche très bien, la preuve je l'utilise pour te répondre là !! :)
[^] # Re: dev
Posté par El Titi . Évalué à 10.
[^] # Re: dev
Posté par bubar🦥 (Mastodon) . Évalué à 2.
http://www.thewildernessdowntown.com
[^] # Re: dev
Posté par GnunuX (site web personnel) . Évalué à 5.
Je viens de tester (avec firefox 4 beta sous GNU/Linux) sur un MSI pas du tout puissant ... ca fonctionne bien.
[^] # Re: dev
Posté par Grunt . Évalué à 2.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: dev
Posté par ナイコ (site web personnel) . Évalué à -1.
For the best viewing experience, we recommend downloading Google Chrome and trying this site again.
C'est quoi ce truc ? On se croirait revenu à l'époque du "Optimisé pour IE uniquement" !?
[^] # Re: dev
Posté par ナイコ (site web personnel) . Évalué à 1.
Je me prends à rêver d'un FF4 ou Chrome pour voir ce film interactif en vitesse réelle...
[^] # Re: dev
Posté par bubar🦥 (Mastodon) . Évalué à 3.
Et utilises le binaire de la Fondation Mozilla directement, si tu souhaites tester FireFox 4 beta. L'important c'est les Logiciels Libres, non la distribution. En plus tu fera plaisir à la MoFo, vu qu'ils "ralent" après le faible nombre de testeurs. Ils se décacarssent a fabriquer Firefox, et se décarcassent à nous filer un binaire fonctionnel (moyennant une règle en plus pour selinux chez ceux utilisant cette solution) et propre pour le systeme (tu peux le coller dans /opt par exemple, puis le lancer avec un simple " ./firefox -no-remote -ProfileManager " et hop :) :) :)
Tout comme pour Chrome, ou tu peux prendre le rpm de Google, il fonctionne sans problème sur ta mandriva (moyennant l'install des dépendances, bien sûr)
/mode trol off/ (tiens ça vaut bien un petit texte sur "l'utilisation des logiciels libres par les distributions, le pouvoir, l'utilisateur, le système" qui pourrait même compléter le fameux howto "comment détruire une communauté en 10 points", peut être, peut être... en fait juste une mise en valeur du point numéro 1 : "Rendez le projet dépendant d’outils complexes" ...
[^] # Re: dev
Posté par bubar🦥 (Mastodon) . Évalué à 1.
# performances légèrement inférieures à la version stable
Posté par Phil Actaire . Évalué à 5.
Est-ce que ce sont des versions de développement pré-compilées ou tu l'as fais toi-même ?
[^] # Re: performances légèrement inférieures à la version stable
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: performances légèrement inférieures à la version stable
Posté par Paul Rouget . Évalué à 5.
# 32 ou 64 bits?
Posté par Donk . Évalué à 3.
[^] # Re: 32 ou 64 bits?
Posté par BAud (site web personnel) . Évalué à 2.
non l'important, c'est quelle distribution ? (et là, c'est le drame :D)
[^] # Re: 32 ou 64 bits?
Posté par patrick_g (site web personnel) . Évalué à 3.
Impossible de tester chez moi sur mon laptop sous Hardy 8.04.....Y'a qu'au boulot que j'ai une heure à perdre ;-)
[^] # Re: 32 ou 64 bits?
Posté par patrick_g (site web personnel) . Évalué à 3.
Mais bon ce ne sont pas les perfs absolues qui comptent. Je crois que ce qui est le plus intéressant ce sont les performances relatives entre les 4 navigateurs testés.
[^] # Re: 32 ou 64 bits?
Posté par Olorim . Évalué à 8.
Encore mieux, le faire aussi entre le 32 et le 64 bits.
T'as pas 15 ou 20 heures à tuer des fois?
# Trop cool... Mais quel intérêt ?
Posté par Pinaraf . Évalué à 7.
Ça sert à quoi ?
Quand on voit les performances graphiques de Firefox ou Chrome, ils feraient mieux d'arrêter de se bagarrer sur le JS et de passer aux autres problèmes. Ça tombe bien, ils commencent à le faire, mais il a quand même fallu un sacre bout de temps avant qu'ils n'y pensent.
Il y a quelques temps, j'avais pour rire testé un ou deux benchmarks de microsoft à la fois sur firefox, arora et konqueror (KHTML). Le vainqueur du benchmark fut .... konqueror, pour ses performances graphiques au dessus de celles de firefox et d'arora.
J'espère que l'utilisation de l'OpenGL dans Firefox fera avancer les choses.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Paul Rouget . Évalué à 10.
Par exemple, pour avoir un meilleur résultat sur SunSpider, on a du se prendre la tete sur la gestion des dates et sa gestion du daylight (rien de critique niveau perf ici).
Donc la compétition, c'est bien, mais de temps en temps, ça a des conséquences absurdes.
> il a quand même fallu un sacre bout de temps avant qu'ils n'y pensent.
Oui, on est trop bête :) On avait oublié.
1. les gens qui font JS ne sont pas les mêmes qui font GFX
2. utilisé XRender sous Linux, c'est arrivé bien avant la versoin 4 (Fx 2 je crois)
3. OpenGL c'est juste le compositing, ça ne rendra pas rapide ce qui est lent aujourd'hui. C'est plutôt aux drivers de s'améliorer (ou alors on fait comme Chrome, on utilise pas les libs du systems, et on fait tout à la main)
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Pinaraf . Évalué à 4.
C'est pas ce que j'ai dit, c'est juste que c'est "à la mode" que depuis que Microsoft en parle finalement, avant, à part quand y'a eu le support de cairo dans mozilla, j'ai pas souvenir d'avoir entendu parler d'accélération graphique.
Et si y'a déjà de l'accélération graphique dans Firefox sous Linux actuellement, ça veut dire qu'elle est largement défaillante vu que Konqueror ne fait aucun effort particulier là dessus et a des performances graphiques supérieures...
(NB: Chrome est pas mieux que Firefox pour les perfs graphiques sous Linux)
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par ecyrbe . Évalué à 3.
Peut tu nous dire, si le support de Direct2D sera rétroporté sur la version officielle de Cairo 1.10?
Est-ce que justement, le nouveau Backend OpenGL de Cairo ne fait pas un peu plus que permettre le compositing, mais aussi d'accélérer le rendu 2D comme pour Direct2D?
Vu que des drivers Gallium3D sous linux commencent à être utilisables et qu'il y a un support (certes encore incomplet) d'OpenVG, y aura il moyen d'activer ce dernier aussi sous linux? vu que cairo supporte aussi OpenVG...
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par patrick_g (site web personnel) . Évalué à 4.
Je trouve que ça c'est vraiment exaspérant. Je suis connecté à mon disque dur USB, je lance une opération de copie assez lourde de mon laptop à mon disque dur et en attendant je surfe un peu...du moins j'essaye de surfer car en vérité toute l"interface de FF est bloquée.
Là dessus Chrome/Chromium est bien plus performant.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Concernant le blocage dû au IOs, je croyais que c'était un problème d'abus de fsync() par SQL lite. Il me semblait que du boulot avait été fait dans ce sens sur Linux, pour que le fsync() passe en priorité sur les autres commandes et sur SQL lite pour diminuer l'usage de cette primitive.
"La première sécurité est la liberté"
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Jux (site web personnel) . Évalué à 3.
C'est vrai que c'est le gros truc exaspérant qui me fait lorgner du côté de chromium.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par pascalc . Évalué à 2.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par DLFP est mort . Évalué à 3.
J'utilise ça : http://miyafx.blogspot.com/2009/03/sqlite-firefox.html mais il y a d'autres addons dans le genre. Tu peux aussi le faire avec l'outil en ligne de commande de SQLite.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par defmonkey . Évalué à 2.
Mouahahaha. Pas du tout. Des réponses DNS trop longues arrivent aussi à bloquer ff. Et j'en souffre régulièrement au boulot. Me souviens plus du bug, mais en gros ya des trucs bloquants qui sont faits dans un thread qui gère l'UI. Et donc c'est pas 1 onglet qui est bloqué, c'est *tout* ff. Genre http://forums.mozillazine.org/viewtopic.php?t=14442 .
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Fabimaru (site web personnel) . Évalué à 2.
http://www.dannychoo.com/post/en/25789/Malaysian+Food.html
(et toutes les galeries d'images de ce site), le défilement rame avec Firefox 3 (Linux amd64) alors que les navigateurs Webkit, Konqueror et Firefox 4 sont fluides. Parfois j'utilisais un de ces derniers rien que pour voir ce site.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Fabimaru (site web personnel) . Évalué à 1.
Scénario parano: Google a fait ces modifs pour donner mauvaise réputation à leur concurrent.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par B16F4RV4RD1N . Évalué à 2.
En tout cas, j'ai été impressionné par la fluidité de FF4 en version beta (avant même l'optimisation js), sur des jeux en lignes qui utilisaient bcp js, pour des sites avec des effets graphiques un peu lourd, ou utilisant les effets d'arrondi et d'ombre html5, c'est bien réactif par rapport à FF 3.6
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: Trop cool... Mais quel intérêt ?
Posté par imr . Évalué à 4.
Eh ben, on est mort.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par DLFP est mort . Évalué à 6.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par imr . Évalué à 10.
Nouveau fait tourner les jeux de 97. Encore 2 ans et il fera tourner warsow, encore 2 ans et on pourra activer le compositing. Entre temps, les desktop seront en opengl 3 voire plus donc ça merdera toujours.
Les drivers ati sont tellement biens qu'on ne sait plus combien il y en a (2 ou 3 à l'heure actuelle? de libres, hein) ni quelles cartes ils supportent, ni de quelle qualité de support on parle puisque c'est variable par carte et par driver.
Et quant aux drivers de cartes intel (que j'ai eu la couillonerie d'acheter depuis quelques années parce qu'on m'avait dit comme toi "c'est trop bien, c'est libre, ça marche mieux" sans préciser que mieux, ça ne veut pas dire complètement) tous les 2 ans ils décident de changer quelque chose soit dans les drivers soit dans xorg parce que ça va être trop trop mieux et ça pète tout pour une partie de la population captive de ces cartes.
En ce moment, ben comme d'hab, pour les possesseurs de i8xxx, c'est la roulette russe suite à des changements récents:
https://lists.ubuntu.com/archives/ubuntu-x/2010-September/00(...)
et pour des fonctions de base ben pas mieux avec les 945 et autres:
http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma(...)
Autant j'ai du respect pour les gens qui disent "moi je veux un système 110% libre, donc je prends une carte qui a des drivers libres" autant je trouve très con de mentir sur l'état réel du support de ces drivers parce qu'après ça se retourne contre les projets libres qui les utilisent.
On blame déjà KDE4 pour des problèmes qui sont causés par les drivers intel, des fonctionnalités openGL qui sont mal supportées voire pas supportées et le driver rapporte qu'il les supporte.
Donc si l'accélération GPU est utilisée maintenant par les browser ou d'autres softs, ça veut dire que bientôt on reprochera ce genre de crashs à google (et ça sera probablement un complot pour dominer le monde) ou à mozilla (et ça sera problablement parce que la mofo se débrouille mal).
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par manatlan (site web personnel) . Évalué à 1.
J'avais failli ne pas résister aux sirènes des cartes/drivers libres quand j'ai changé de config. Mais j'ai tellement tellement de mauvais souvenirs d'ATI et/ou intel (sur eeepc) ... que j'ai bêtement repris une carte nvidia. Drivers proprios, mais rien à redire ...
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par DLFP est mort . Évalué à 5.
Grmbl. Ça fait un moment que c'est plus le cas. radeonhd est abandonné, tout est unifié par le driver "ati". Le support est détaillé, et ça dépend uniquement de la génération : http://www.x.org/wiki/RadeonFeature
En gros, tu peux être sûr que toute carte Radeon <5000 aura un support très complet. Je joue à OpenArena, Nexuiz, etc. avec une Radeon HD 4670.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Albert_ . Évalué à 1.
sous windows il y a un truc pour swapper de l'une a l'autre a chaud, sous linux cela arrive un peu (redemarrage de xorg obligatoire) mais d'apres ce que j'avais vu niveau consommation la carte conseille pour consommer moins, Intel, consommait autant voir plus que ATI (en fait par consommation je veux dire que l'evaluation de la fin de la batteriene penchait pas en faveur de la carte Intel). Je pourrai faire le test en redemarrant et en activant chaque carte l'une apres l'autre mais bon comme je ne fais pas exactement la meme chose au meme moment je ne pense pas que cela soit valable comme test donc j'aimerai bien un avis plus "theorique" sur le sujet.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par DLFP est mort . Évalué à 2.
Après, si les drivers Intel gèrent mal l'économie d'énergie, ce que tu dis me semble bien possible. Ou alors les deux cartes sont quand même « allumées » quoi que tu fasses.
Je savais que nVidia faisait ça, parce que leur cartes sont assez gourmandes, je savais pas pour ATI.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Peux-tu expliquer plus ? En gros, le problème est d'avoir une sorte de lib vectoriel accéléré ?
"La première sécurité est la liberté"
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pouillèmes qui peuvent représenter x1.5 ou x2, donc non ce n'est pas négligeable !
"La première sécurité est la liberté"
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Pinaraf . Évalué à 5.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il suffit de voir le comportement des appli google pour voir que cela serait mieux, d'avoir un peu plus de vitesse (le tableur surtout).
"La première sécurité est la liberté"
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Pinaraf . Évalué à 2.
Ça peut très bien être un problème au niveau du DOM, au niveau de l'affichage...
Le JS a atteint, et ce depuis 2 ans facilement sur les navigateurs modernes, un niveau suffisant pour 99% des applications qu'on pourrait en faire. Quel est l'intérêt d'optimiser ça encore ?
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par El Titi . Évalué à 7.
Un niveau suffisant pour 99% des applications qu'on pourrait en faire. Quel est l'intérêt d'optimiser ça encore ?
Encore un ptit doigt ?
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par mansuetus (site web personnel) . Évalué à 10.
Ça me rappelle une phrase à propos de 640 Ko...
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Vlobulle . Évalué à 1.
Tu sous-entends une limitation technique inhérente au Javascript ?
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par tiot (site web personnel) . Évalué à 3.
Ça doit être la principale raison pour laquelle chrome s'est lancé dans la course aux navigateurs.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par flagos . Évalué à 2.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Déjà que l'intérêt d'un tableur est plus que discutable, alors un tableur en Javascript qui pue...
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# patrick, avec Firebug activé ?
Posté par pascalc . Évalué à 7.
Sunspider:
Firefox 3.6 : 1300ms
Firefox Trunk : 485ms
Chromium dev: 333ms
Comme tu peux le constater, l'écart est bien plus faible sur ma machine que sur la tienne entre Chromium et Firefox que ce soit la version du trunk ou celle de dev. Par ailleurs j'ai presque un facteur 3 entre Fx3.6 et 4 alors que tu n'as quà peine un facteur 2,
En fait tu as même des perfs nettement plus basses que mon collègue qui a une machine à 1,87Gz et qui a 600ms sur Sunspider!
Pour avoir des performances dégradées similaires à tes résultats, il faut que le JIT soit désactivé chez moi, ce qui arrive quand on installe Firebug par exemple.
La question est donc est-ce que tu as Firebug d'installé dans tes profils et est-ce que tout simplement le jit est activé dans about:config ? :)
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 1.
Non pas de firebug d'installé. En fait j'ai désactivé toutes mes extensions Firefox avant de lancer le test.
Mais bon je ne crois pas qu'on puisse comparer les perfs entre ta machine et la mienne. Le comparatif n'a vraiment du sens qu'entre divers navigateurs installés sur la même machine.
Par exemple quel est ton OS ? Mon test a été effectué sous WinXPSP3 et Dieu seul sait quels sont les process qui tournent en arrière plan (par exemple au boulot on a un antivirus en tâche de fond).
[^] # Re: patrick, avec Firebug activé ?
Posté par pascalc . Évalué à 3.
Pour le fun, j'ai lancé Firefox Trunk dans un XP à l'intérieur d'une VM sur cette même machine et même là, avec des perfs qui sont celles d'une VM c'est à dire très dégradées, j'ai un résultat deux fois meilleurs que les tiens (658ms).
Je veux bien que l'on ait des configs différentes mais tes résultats sont tout trois fois plus lents que les miens et restent deux fois plus lents quand je passe par une VM donc à mon avis, tu as pas le JIT activé dans tes prefs. Tu peux réessayer avec un profil vierge?
[^] # Re: patrick, avec Firebug activé ?
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: patrick, avec Firebug activé ?
Posté par pascalc . Évalué à 1.
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: patrick, avec Firebug activé ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 1.
http://news.softpedia.com/news/No-64-bit-x64-Firefox-4-0-32-(...)
[^] # Re: patrick, avec Firebug activé ?
Posté par pascalc . Évalué à 1.
http://nightly.mozilla.org/
[^] # Re: patrick, avec Firebug activé ?
Posté par Jean-Max Reymond (site web personnel) . Évalué à 2.
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: patrick, avec Firebug activé ?
Posté par Phil Actaire . Évalué à 2.
javascript.options.jit.chrome
javascript.options.jit.content
Je pense que c'est la seconde qui importe ici mais chez moi, les 2 sont à true.
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: patrick, avec Firebug activé ?
Posté par pascalc . Évalué à 2.
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: patrick, avec Firebug activé ?
Posté par windu.2b . Évalué à 2.
1 http://support.mozilla.com/fr/kb/Gestion+des+profils
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 3.
Donc j'ai refait le test sunspider avec la version trunk sur un profil vierge.
Résultat : 1257 ms
Je pense que c'est dans la marge de fluctuation statistique par rapport au score de 1281 ms que j'avais trouvé précédemment.
Ensuite je suis allé voir le about:config de la version trunk et là, surprise, il y a des choix en plus par rapport aux choix présents dans la 3.6.
On remarque notamment javascript.options.methodjit.chrome qui chez moi était à false (tous les autres sont à true). Je l'ai donc remis lui aussi à true et, bis repetita, j'ai relancé le test sunspider.
Résultat 1271 ms.
Donc les perfs sur ma machine sont bien de cet ordre là et je reste très loin des 658ms annoncés par pascalc.
Sans doute ce salopiot d'antivirus qui me bouffe mes cycles CPU.
[^] # Re: patrick, avec Firebug activé ?
Posté par allcolor (site web personnel) . Évalué à 4.
Sans doute ce salopiot d'antivirus qui me bouffe mes cycles CPU.La question est alors pourquoi chrome/chromium semble insensible à ce salopiot ? :D
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 2.
Cela explique pourquoi je n'ai pas les mêmes performances que pascalc.
[^] # Re: patrick, avec Firebug activé ?
Posté par pascalc . Évalué à 3.
Par ailleurs, tu as présenté ton article comme une comparaison objective et scientifique des performances de Firefox par rapport à Chrome, hors ce n'est clairement pas le cas et ça aurait été bien de le mettre en préambule.
Je te rappelle que sur une machine très équivalente à la tienne avec Firefox qui tourne dans un XP virtualisé, j'éxplose les perfs de ta machine sous Firefox.
Au passage, chez moi la version de dev de Chrome 7 a les mêmes perfs que les nightlies de Chromium et est nettement plus rapide que la version stable de Chrome (350ms versus 550 pour la stable), donc même pour Chrome tes résultats sont douteux.
[^] # Re: patrick, avec Firebug activé ?
Posté par nicolas . Évalué à 3.
[^] # Re: patrick, avec Firebug activé ?
Posté par patrick_g (site web personnel) . Évalué à 2.
Sinon je ne peux que rester perplexe quand aux résultats que j'ai constaté sur ma machine. Je ne sais pas vraiment ce qu'est "une comparaison objective et scientifique" telle que la réclame pascalc. J'ai indiqué les caractéristiques de mon ordinateur, j'ai effectué les tests sur trois benchs différents, j'ai refait les tests avec un profil propre, j'ai vérifié les options du about:config...que puis-je faire de plus ?
On verra bien au moment de la sortie effective de FF4.
[^] # Re: patrick, avec Firebug activé ?s
Posté par nicolas . Évalué à 2.
Du coup, « une comparaison objective et scientifique » n’est pas nécessairement pertinente.
Ou alors c’est bêtement l’antivirus ?! Il est quand même très probable que ça vienne de la partie logicielle. xD
# WebGL
Posté par thedidouille . Évalué à 1.
WebGL fonctionne avec Chromium chez moi, avec des driver open source (i965), supportant OpenGL 2.1 et GLX_SGIX_pbuffer, alors pourquoi pas firefox?
Promis, après, j'utilise plus Chromium.
[^] # Re: WebGL
Posté par pascalc . Évalué à 1.
[^] # Re: WebGL
Posté par thedidouille . Évalué à 1.
[^] # Re: WebGL
Posté par pascalc . Évalué à 1.
[^] # Re: WebGL
Posté par Alexandre . Évalué à 1.
# Hé
Posté par Gwen Gaumend . Évalué à -4.
J'utilise firefox.
Avec un nokia n95, je m'en sers comme modem, et c'est grâce à lui si vous me lisez.
C'est pas beau la technologie ?
Ben si.
# Comparatifs benchmarks quotidiens
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
On voit nettement les améliorations par rapport aux autres moteurs JS, surtout ces derniers jours.
Les tests sont effectués avec les versions "standalone" des moteurs JS (donc hors navigateur). Donc pas de risque de parasitage de performance par d'autres éléments du navigateurs (moteur graphique, thread reseaux ou autre). Ce sont des résultats de perf pures donc.
Un peu d'explication pour ceux qui ont la flemme de lire la FAQ.
à l'origine, il y a le moteur SpiderMonkey : c'est un simple interpreteur JS, pas d'optim.
Il y a eu ensuite TraceMonkey = SpiderMonkey + technique d'optimistation dites "tracing", appliquée principalement sur les boucles, et qui est plus performantes que de la simple compilation JIT. Mais malheureusement, cette technique ne fonctionne pas dans tout les cas, donc il y a du code JS qui reste interprété à la volée. Les perfs de tracemonkey, c'est la courbe orange.
Il y a eu ensuite JaegerMonkey = SpiderMonkey + technique d'optimisation dites "jit" : le code JS est "compilé". C'est la technique utilisée dans le moteur js de webkit, avec le générateur de code machine Nitro, et celle utilisée dans v8, le moteur de chrome. D'ailleurs, JaegerMonkey utilise Nitro (oui, oui, une brique d'un "concurrent", vive l'open source !). Les perfs de jaeger monkey = courbe orange.
Et depuis quelques jours, ils ont fusionné les deux techniques (courbe violette) dans le même moteur JS. Il n'y a donc plus de code JS interprété. Utilisation du tracing quand c'est possible (car plus rapide que du simple compilé en theorie), et utilisation du JIT pour le reste du temps.
Ils arrivent donc maintenant à rattraper les autres moteurs JS. Ils ont encore pas mal d'optimisation à faire, ce qui va arriver dans les prochains jours.
On espère donc que la courbe violette descende en dessous des autres, et qu'il y ait enfin un "YES" à la place du "NO" :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.