Je pense que le fait qu'il n'y presque (il existe de rares forks de firefox) que la mofo qui utilise gecko joue aussi: moins de contributeurs. Reste maintenant à déterminer pourquoi tant d'autres projets préfèrent webkit à gecko...
il doit dès le départ initialiser beaucoup de choses pour que la navigation soit opérande (la gestion de la mémoire par exemple qui est très complexe)
Genre... la gestion de la mémoire, toutes les applications natives le font hein... avec plus ou moins de bonheur, certes.
A moins que, comme certains développeurs de jeux vidéo, FF ne fasse que de gros malloc et gère ensuite lui-même les blocs mémoire (surcharge de new et delete en C++, détournement de *alloc et free en C et C++ pour qu'ils pointent vers des fonctions custom)?
Je serai surpris (parce que l'augmentation de la consommation mémoire de FF me semble trop douce pour ce type de modèle, à moins que les chunks ne soient vraiment petits, mais je reconnais n'avoir pas creusé la question), mais pourquoi pas (et puis, vue la quantité de parsing qu'il doit gérer, ce ne serait pas débile).
Sans compter qu'il faut charger l'historique et les marques pages
C'est vrai, tous les navigateurs ne le font pas. J'en vois au moins... 1 seul en fait (uzbl, parce que le but est d'être minimaliste). Même dillo et netsurf le font (mais pas de JS, nous sommes d'accord).
Et Firefox aussi doit identifier certains éléments matériels pour savoir s'il peut activer des choses comme l'accélération matérielle pour WebGL ou les codecs vidéo.
Je doute qu'il implémente des pilotes graphiques. A mon avis, il fait comme tout le monde: il demande à l'os quelle version d'oGL est dispo, et ça ne prend pas tant de temps que ça (pas rapide d'initialiser un contexte opengl à première vue, ok, mais on est loin d'expliquer un temps de plusieurs secondes avec ça).
Le pire, c'est qu'au fond je suis d'accord avec toi: un browser, c'est complexe. Ceci dit, tu sembles chercher la petite bête pour défendre à tout prix firefox.
Personnellement, je me pose juste les questions suivantes: Haiku utilise une vieille version de webkit.
Quid du respect de la chiée de nouveaux standards de plus en plus complexes apparus depuis?
Quid des sandbox?
Firefox et les browsers multi-onglets que je connais tendent à avoir plusieurs processus et non threads pour sandboxer et éviter qu'un crash d'un onglet ne ferme le brouteur. Et celui de Haiku? Lancer un processus par page (si ce n'est plus), c'est autrement plus lourd que lancer 1 thread par page...
Bref, oui, il y a des raisons au "long" démarrage de firefox (j'ai vu pire perso), et il est probable que ça pourrait être amélioré (le code est pas tout neuf non plus, je ne serai pas surpris qu'il y ait plus que quelques dizaines de KLoc de dette technique, après tout l'origine date des années 90 hein) mais je m'interroge sur comment Haiku serait plus rapide en offrant la même sécurité et robustesse, en se basant sur du code obsolète...
[^] # Re: Réécrire l'histoire
Posté par freem . En réponse à la dépêche Haiku a 16 ans. Évalué à 1.
Je pense que le fait qu'il n'y presque (il existe de rares forks de firefox) que la mofo qui utilise gecko joue aussi: moins de contributeurs. Reste maintenant à déterminer pourquoi tant d'autres projets préfèrent webkit à gecko...
Genre... la gestion de la mémoire, toutes les applications natives le font hein... avec plus ou moins de bonheur, certes.
A moins que, comme certains développeurs de jeux vidéo, FF ne fasse que de gros malloc et gère ensuite lui-même les blocs mémoire (surcharge de new et delete en C++, détournement de *alloc et free en C et C++ pour qu'ils pointent vers des fonctions custom)?
Je serai surpris (parce que l'augmentation de la consommation mémoire de FF me semble trop douce pour ce type de modèle, à moins que les chunks ne soient vraiment petits, mais je reconnais n'avoir pas creusé la question), mais pourquoi pas (et puis, vue la quantité de parsing qu'il doit gérer, ce ne serait pas débile).
C'est vrai, tous les navigateurs ne le font pas. J'en vois au moins... 1 seul en fait (uzbl, parce que le but est d'être minimaliste). Même dillo et netsurf le font (mais pas de JS, nous sommes d'accord).
Je doute qu'il implémente des pilotes graphiques. A mon avis, il fait comme tout le monde: il demande à l'os quelle version d'oGL est dispo, et ça ne prend pas tant de temps que ça (pas rapide d'initialiser un contexte opengl à première vue, ok, mais on est loin d'expliquer un temps de plusieurs secondes avec ça).
Le pire, c'est qu'au fond je suis d'accord avec toi: un browser, c'est complexe. Ceci dit, tu sembles chercher la petite bête pour défendre à tout prix firefox.
Personnellement, je me pose juste les questions suivantes: Haiku utilise une vieille version de webkit.
Quid du respect de la chiée de nouveaux standards de plus en plus complexes apparus depuis?
Quid des sandbox?
Firefox et les browsers multi-onglets que je connais tendent à avoir plusieurs processus et non threads pour sandboxer et éviter qu'un crash d'un onglet ne ferme le brouteur. Et celui de Haiku? Lancer un processus par page (si ce n'est plus), c'est autrement plus lourd que lancer 1 thread par page...
Bref, oui, il y a des raisons au "long" démarrage de firefox (j'ai vu pire perso), et il est probable que ça pourrait être amélioré (le code est pas tout neuf non plus, je ne serai pas surpris qu'il y ait plus que quelques dizaines de KLoc de dette technique, après tout l'origine date des années 90 hein) mais je m'interroge sur comment Haiku serait plus rapide en offrant la même sécurité et robustesse, en se basant sur du code obsolète...