Avec la fermeture du bogue 450160, le score du futur Firefox 3.1 arrive à 87 / 100.
Étiquette : shiretoko
Les options d’optimisation agressives sont-elles inutiles ?
Dans une page de leur wiki les développeurs de Mozilla Firefox et des outils associés déclarent, je cite :
For Firefox 3 builds, please use –enable-optimize without flags.
Our testing has shown that different parts of Mozilla run faster at different optimization levels. For example, cairo, pixman and sqlite are compiled at -O2 because they are fastest at that level while the JS engine is fastest at -Os. [3] Don’t use –enable-optimize as a place to pass in random compile flags. That’s a global setting that sets optimization levels throughout the source tree and is different depending on the module being compiled.
If you still need to pass in other non-optimization flags to the compile, please use CFLAGS and CXXFLAGS instead of passing them to –enable-optimize.
Ce qui donne traduit :
Pour la compilation de Firefox 3, veuillez utiliser –enable-optimize sans options.
Nos tests nous ont montrés que les différentes parties de Mozilla sont plus rapides à différents niveaux d’optimisation. Par exemple, cairo, pixman et sqlite sont compilé en -O2 car ils sont plus rapide à ce niveau tandis que le moteur JS est plus rapide avec -Os. N’utilisez pas –enable-optimize comme un endroit pour insérer des options de compilations divers. C’est un réglage global qui définit les niveaux d’optimisation tout au long du code source et il diffère en fonction du module qui est compilé.
Si vous avez toujours besoin de passer des options de non optimisation au moment de la compilation, veuillez utiliser CFLAGS et CXXFLAGS au lieu d’utiliser la ligne –enable-optimize.
Continuer la lecture de « Les options d’optimisation agressives sont-elles inutiles ? »
Concours de vitesse en javascript…
Dans un précédent billet, je parlais de l’impact de TraceMonkey sur les tests concernant la vitesse d’exécution de Javascript. J’ai donc voulu tester les performances de Firefox 3.0.1, Shiretoko pré-bêta1, Opera 9.60 bêta et du dernier Webkit en date sur les tests proposés par Google pour le moteur de javascript V8 qui équipe Google Chrome.
La lecture du résultat est simple. Avoir 100 comme score est la base. Plus le score est important, mieux c’est.
Continuer la lecture de « Concours de vitesse en javascript… »
Et SeaMonkey 2.0 dans tout cela ?
Alors que Shiretoko alpha2 vient juste de sortir (), j’ai envie de parler d’un certain SeaMonkey 2.0, qui se basera sur un Gecko 1.9.1 final (base de Firefox 3.1 alias Shiretoko).
Un bogue intéressant, c’est le bogue 394522 : « Migrate SeaMonkey preferences panes to use <preferences> »
En clair, c’est une volonté d’utiliser les outils du toolkit de Mozilla Firefox et de laisser tomber lentement mais surement le vieux code XPFE qui commence à prendre la poussière.
En effet, si on ouvre les préférences d’un SeaMonkey (version de développement) récente, on s’aperçoit d’un message, qui annonce que la migration est en route.
En ce qui concerne l’abandon du code XPFE dans SeaMonkey, le code a connu une purge dans ce domaine depuis quelques temps. Cf les bogues 380786 et 386906.
D’ailleurs l’alpha1 de SeaMonkey 2 ne saurait tarder, le code devant être gelé aux alentours du 9 septembre.
Ce sera une bonne nouvelle pour les fans du successeur de la suite Mozilla dont les buts sont précisés sur cette page.
Vrac’ons rapidement.
Un petit vrac rapide, sur le pouce.
- Selon Kaspersky, Nimda un ver de 2001 continue de faire des ravages. Pour info, ce ver utilise une faille corrigée en l’an 2000 corrigée sur IIS 4 et 5…
- Le gel du code pour la première béta de Firefox 3.1 est repoussé d’environ 3 semaines. Prévu à l’origine pour le 9 septembre, le gel du code est repoussé au 30 septembre. Donc Firefox 3.1 béta1 en octobre, la béta 2 en novembre, et la version finale en janvier 2009 ?
- Google Chrome, le navigateur de Google vient de sortir. Et il se fait incendier par rapport à sa licence d’utilisation…
C’est tout pour aujourd’hui.

