Cela n'a échappé à personne, les prochaines version d'Epiphany, le navigateur officiel de Gnome, sera prochainement propulsé par WebKit, le même moteur que Konqueror et Safari. Et ce "prochainement" est suffisamment proche pour le moteur soit activé par défaut dans la version de développement du navigateur. Alors j'avais envie d'aller voir où en était l'avancement...
Compilation
Pour ce qui est de la librairie GTK/WebKit, j'ai bien tenté de la compiler à la main mais il semble que le trunk soit méchamment cassé pour l'instant. Je me suis donc rabattu sur la version en dépôt testing de mandriva.
Ensuite, récupération des dernières sources d'Epiphany :
et enfin un bien classique ./autogen --prefix=/opt ; make ; sudo make install.
L'utilisation du /opt m'évite de torpiller l'installation existante d'Epiphany.
Petits tests
Côté tests, rien de bien violent. Juste un petit chrono à la main pour tester le temps de démarrage à froid et à vide (page de démarrage vide et tout cache système vidé), à chaud et à vide (second démarrage), à froid avec une page à affiche au démarrage (la page de garde d'artistan).
| Type | Epiphany/WebKit | Epiphany/Gecko | FireFox2 | FireFox3 |
|---|---|---|---|---|
| à froid | 3 | 6.5 | 5.6 | 6.5 |
| à chaud | 1.1 | 2.5 | 1.38 | 1.65 |
| page | 5.1 | 8.87 | 7.2 | 7.3 |
| dhtml | 60 | 609 | 658 | 257 |
| javascript | 9 | 64 | 64 | 50 |
A noter que j'ai désactivé toutes les extensions de FireFox pour ces tests.
Conclusion
Lorsque l'on utilise cette mouture d'Epiphany, la vitesse ressentie est très proche de ce que je connaissais avec Konqueror. Les chiffres le confirment pour tous les domaines testés. Les résultats de rendu de page, JavaScript et DHTML sont juste étonnant de vélocité et confirme que la vitesse de WebKit n'est pas une légende.
A noter la proximité logique des résultats Epiphany/Gecko et FireFox2 qui utilisent la même infrastructure et les nets progrès de FireFox3 qui surpassent Epiphany/Geck sur tous les tableaux.
Maintenant cette version n'est pas encore très sèche. Les pages "clignotent" aux transitions, certains rendus de contrôles sont bizarres et le correcteur orthographique est non fonctionnel (et non activable vu que about:config ne fonctionne pas). Mais dans l'ensemble, c'est très prometteur.
- répondre
AP , le 13 August, 2008 - 05:18Je suis bluffé par deux choses :
- répondre
Ulhume, le 13 August, 2008 - 06:59@AP
Yep, j'avoue que même si je ne m'attendais pas à ce que Gecko "sur-performe" WebKit (aka KHML) j'avoue que dans ces proportions là c'est assez étonnant. Les deux seuls tests un peu "sans intérêt" sont le démarrage "warm" et le chargement de page. Avec un chrono à la main pas facile d'avoir des résultats fiables. Je reste donc réservé quant à ces deux résultats et donc aux vitesses comparées de rendu pur. Si quelqu'un connaît un vrai test dans ce domaine , au sens d'automatisable, ça m'intéresse. C'est le cas des deux derniers qui même s'il ne testent pas tout DHTML/Javascript sont plus "objectifs". Et c'est aussi là que les différences sont les plus étonnantes et difficilement discutables. D'un autre côté même si KHTML a toujours été plus rapide que Gecko, j'imagine que la patte Apple, qui a du sérieusement l'optimiser pour des puces moins puissantes comme celle sur l'iPhone (un Xscale je crois), n'y est pas pour rien non plus. Bref, c'est rapide
Merci pour ton deuxième point
- répondre
Sonny, le 13 August, 2008 - 15:07Il aurait fallu faire le test firefox avec un profile vierge
- répondre
Ulhume, le 13 August, 2008 - 22:49@Sonny Le profile _est_ vierge, j'ai juste désactivé la seule extension que j'avais chargée (et pas de plugins
) à savoir scrapbook. D'aillleurs je te remercie pour cette astuce, effectivement, FireFox c'est comme windows, de temps en temps faut tout virer pour retrouver la vélocité des débuts 
Maintenant à la limite cela impacte sur les temps de démarrage, mais pas ceux de rendu, ni javascript, ni DHTML, va falloir trouver autre chose
Poster un nouveau commentaire