Le développement de Gecko a débuté en 1998, mais la plupart des devs de Gecko avaient déjà une grosse expérience puisqu'ils venaient des équipes de Netscape 4 et précédent. Et puis le développement de Gecko (qui se faisait au sein de la societé Netscape), était fait par des devs à temps complets. Ce n'était pas le cas des devs de KHTML. le developpement de kHTML (tel qu'il est aujourd'hui) n'a réellement débuté qu'en 1999. À ceci il faut ajouter que Gecko, à la même époque, supportait non seulement HTML, mais aussi MATHML et surtout XUL/XBL, qui était une révolution à l'époque. Et puis certaines briques comme NSS (1) et NSPR (2) ont été reprises de feu Netscape 4.
Bref, Gecko a avancé plus vite que kHTML (sous la pression aussi de Netscape/AOL). Par contre il n'a pas forcément avancé vite de la meilleur façon. On se souvient de Nescape 6 sortie en 2006, qui n'était franchement pas exemplaire en terme de performance et de stabilité. De l'aveux même des développeurs, Gecko n'était franchement pas prêt.
Et puis, en plus de la non maturité du code, des choix techniques à l'époque du démarrage du projet sont responsables de certaines lourdeurs, qui ont depuis été corrigé, mais qui perdurent encore dans certaines parties du code.
Un exemple d'erreur : l'utilisation de XPCOM (3) à tout les niveaux. C'est un système génial pour l'extensibilité, pour pouvoir ajouter des composants binaires à un executable sans avoir à le recompiler, et pouvoir appeler ces composants dans un contexte javascript. XPCOM permet aussi une meilleur gestion automatique de la mémoire (en tout cas à l'époque). Mais utiliser XPCOM dans le coeur du moteur de rendu a été une erreur, car c'est un système lourd. C'est pourquoi depuis quelques années il y a un processus de "déCOMtamination" dans Gecko, et on commence seulement à en voir le bout du tunnel (c'est long parce que ça concerne des dizaines de milliers de lignes de code). Cette déCOMtamination a permis d'améliorer un peu les perfs dans les dernières versions de Firefox.
Bref, c'est ce genre de passif dont je parlais, entre autre chose.
[^] # Re: gtk ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi chromium est il si rapide sous linux ?. Évalué à 9.
Bref, Gecko a avancé plus vite que kHTML (sous la pression aussi de Netscape/AOL). Par contre il n'a pas forcément avancé vite de la meilleur façon. On se souvient de Nescape 6 sortie en 2006, qui n'était franchement pas exemplaire en terme de performance et de stabilité. De l'aveux même des développeurs, Gecko n'était franchement pas prêt.
Et puis, en plus de la non maturité du code, des choix techniques à l'époque du démarrage du projet sont responsables de certaines lourdeurs, qui ont depuis été corrigé, mais qui perdurent encore dans certaines parties du code.
Un exemple d'erreur : l'utilisation de XPCOM (3) à tout les niveaux. C'est un système génial pour l'extensibilité, pour pouvoir ajouter des composants binaires à un executable sans avoir à le recompiler, et pouvoir appeler ces composants dans un contexte javascript. XPCOM permet aussi une meilleur gestion automatique de la mémoire (en tout cas à l'époque). Mais utiliser XPCOM dans le coeur du moteur de rendu a été une erreur, car c'est un système lourd. C'est pourquoi depuis quelques années il y a un processus de "déCOMtamination" dans Gecko, et on commence seulement à en voir le bout du tunnel (c'est long parce que ça concerne des dizaines de milliers de lignes de code). Cette déCOMtamination a permis d'améliorer un peu les perfs dans les dernières versions de Firefox.
Bref, c'est ce genre de passif dont je parlais, entre autre chose.
(1) http://en.wikipedia.org/wiki/Network_Security_Services
(2) http://en.wikipedia.org/wiki/Netscape_Portable_Runtime
(3) http://en.wikipedia.org/wiki/XPCOM