Pourquoi donc une version linux plus lente que sous windows.
1) bon déjà, faudrait tester des navigateurs de même génération. Comparer un Chromium 4 qui vient de sortir, à une "vieille" version de Firefox, c'est limite. Car en ce moment, les progrés sont énormes ET très rapide. Bref, vaut mieux comparer avec une beta 3.6 de Firefox.
2) comme ça été dit, TraceMonkey n'est pas activé en 64bit dans la version 3.5 de Firefox, mais l'est à priori dans la version 3.6. d'où de grosse différence, puisque c'est alors l'ancien moteur JS non optimisé (SpiderMonkey) qui est utilisé
3) comme je l'ai déjà dit dans un autre commentaire, il n'y a pas de "branche" spécifique à linux ou à windows. C'est le même code, le même trunk. Les deux versions partagent au moins 90% du code, parce que l'objectif de Mozilla (depuis 1998) est justement de limiter de recoder les mêmes trucs pour chaque plateforme. Ainsi donc, c'est exactement le même moteur de rendu, le même moteur JS, la même implémentation DOM, les mêmes sources pour l'interface en XUL (modulo les fichiers CSS et quelques aménagements, comme l'emplacement de l'item de menu Options et autre trucs mineurs de cet acabi) etc..
Et tout ça repose sur une même couche d'abstraction du système, que ce soit d'un point de vue graphique (lib Cairo), ou plus général (fichiers, threads, et cie : lib NSPR)
La grosse différence entre les deux, se situe donc dans l'implémentation de cette couche d'abstraction, tant dans Cairo que NSPR, mais aussi dans le toolkit utilisé (GTK sous linux, win32 sous windows et cie)
Bref, au final, les différences de perfs entre Windows et Linux, se situent principalement dans les accés au système et à l'environnement graphique. De là à dire que le sous-systeme graphique de Windows est plus performant que X... ;-)
Notons aussi que sous linux, on a les problemes de fsync (notament via sqlite). Dans la 3.6, ils ont alors essayé de limité au maximum les accés disques et les requetes SQL, pour palier à ce défaut.
Bref, la faute n'est pas entièrement celle de Mozilla, mais de aussi des libs externes utilisées.
4) la compilation. Sous windows, c'est Visual C++ qui est utilisé. Sous les autres système, GCC. Il parait que VC produit souvent du code mieux optimisé que GCC. Ceci explique peut être cela.
D'une distro à une autre, les libs externes utilisées (sqlite et cie), ne sont pas forcément la même version qu'utilisée dans les builds windows, (qui sont celles largement testées et validées par Mozilla). Peut-être alors a-ton des différences de perfs parce qu'utilisation de libs différentes (plus ancienne par ex). Pure supposition de ma part. Notons aussi que sous windows, tout est compilé en statique.
5) possible que la différence se fait sentir à cause aussi des différences entre options de compil, entre chaque distro et os. Possible aussi que les patchs ajoutés par certaines distro aient des effets de bords..
6) reste aussi le temps passé à optimiser la version Linux. Il y a des développeurs sous linux, mais comme dit Pascalc plus haut, peu de retour, peu de beta testeur, et ne représentent même pas 1% de tout les betas testeurs. Moins de retours -> moins de bug de perf "découverts". D'ailleurs, il est probable que bon nombre de ces 1% des betas testeurs utilisent les binaires vanilla de Mozilla (compilé en static, sans patchs et autre options de compil exotiques), donc peut être avec moins de différences flagrantes. ça rejoint le point 5.
Bon, et sinon, ça râle régulièrement sur ce site, à propos des perfs sous linux (souvent à juste titre, c'est vrai). Mais râler ne suffit pas. Il faut aussi des gens pour tester et pour coder. Alors n'hésitez pas à contribuer ;-)
Les versions Linux et Windows partagent au moins 90% du code, et sont dans la même branche. Les seuls grosses différences, ce sont les couches basses, donc les accès au reste de l'OS (système graphique, système de fichiers etc..)
Le moteur JS, le moteur de rendu etc, tout est absolument identique.
>il ne faut pas oublier que le bailleur de fonds de la mozfo c'est google
Google n'est pas le bailleur de fond. Il n'y a qu'un simple contrat entre la MoCo et Google : argent en echange de trafic. point barre.
Mozilla peut très bien survivre sans google. Si là, maintenant, tout de suite, le contrat était rompu, Mozilla a de quoi survivre pendant 3 ans avec les mêmes dépenses. D'ailleurs, il est possible que Mozilla puisse être auto-financé avec des réductions de dépenses.
>que mon navigateur fasse du webgl, du nacl ou du html5 : comme tu dis, on s'en b....
ouai enfin non, on s'en fout pas, enfin moi non. Parce que je veux que n'importe quel site puisse fonctionner correctement, surtout si il n'utilise que des standards (ou futur standards). Pour un utilisateur, surtout si il n'y connait que pouik en techno, un site qui ne fonctionne pas, c'est un site sur lequel il ne reviendra pas. Et si il tombe sur trop de site qui ne fonctionnent pas, il passe à un autre navigateur (si c'est un utilisateur un peu avancé).
>il vaut être pragmatique !
je pense que Mozilla est très pragmatique. Tiens, une preuve : acid3. ils sont pas à 100% parce qu'ils estiment qu'il y a des choses qui méritent plus d'attention, que le support des fontes SVG (les derniers points à gagner sur acid3 concernent ce support principalement). Et ils ont préférés par ex travailler sur le nouveau format WOFF (http://hacks.mozilla.org/2009/10/woff/ ), qui est un meilleur compromis entre les développeurs et les fondeurs.
>l'émulateur NES en JS (et je sais bien que ce n'est pas non plus un benchmark) tourne infiniment (100x) plus rapidement sous chrome que sous ffox.
La majorité des bottlenecks, que ce soit pour cet émulateur ou les gros sites avec plein de DHTML de partout, ce n'est pas la faute au moteur JS, tracemonkey, mais la faute à notre couche de communication DOM <-> JS.
ils n'ont, et n'auront jamais une extensibilité aussi forte que ce que permet Firefox. Ils sont au niveau en terme de navigation et visite des pages. Maintenant Chrome est loin d'être une plateforme de dev comme l'est Firefox. Faut bien voir ça. Firefox n'est pas qu'un moteur de rendu de page web. Chrome si (avec quelques boutons autour). Peut être que tu t'en fiches, que tu veux qu'un simple browser, mais Firefox n'en serait pas là où il est si il n'avait pas cette formidable extensibilité. Il (ou plutôt XulRunner, sur lequel est bati Firefox) a servi de base à plein d'appli.
>qu'ils seront, ET DE LOIN, les premiers à couvrir html5 (entre autres, pour remplacer gears, qui est une brique importante de l' "os chrome" pour l'offline) ...
euh, tout ce que fait gear, Firefox le fait depuis des lustres il me semble. Faut arreter un peu. En matière de support HTML5, chrome n'est pas si en avance, et Firefox ne prend en rien du retard. Et puis il n'y a pas que HTML5, mais aussi XBL2, et d'autres technos sur lesquels Chrome a encore du retard (à quand une implem XForms par ex, ou MathML).
>Ils ont aussi, à mon sens, un truc que mozilla n'a pas : faire plaisir à l'utilisateur final
ça c'est ton avis propre. Ce n'est pas l'avis des 330 millions d'utilisateurs de Firefox. Et aux dernières nouvelles, la progression de Chrome n'est pas si fantastique que ça, en terme de part de marché (surtout que Firefox continue à bien progresser aussi sur ce sujet). Il va falloir beaucoup de temps, à mon avis, avant que Chrome ne parviennent à rattraper Firefox.
le freeze, c'est dû au fait que toutes les pages web et l'interface (qui est en xul+js), s'exécutent dans le même thread (pour des raisons historiques et techniques, notamment vis à vis des extensions, mais avec le projet electrolysis, ils sont en train de changer ça). Mais ça n'empêche pas Firefox d'utiliser les threads pour tout ce qui est réseau et certains traitements en taches de fond qui ne touchent pas directement l'interface ou une page web (dans la 3.6 par ex, la recherche qui s'effectuent lorsqu'on tape dans la barre d'url se fait maintenant dans un thread).
Notons aussi que grâce aux webworkers (ff3.5), les pages web ont la possibilité de réaliser en javascript des trucs dans un thread séparé, ce qui évite les temps de "chargements" trop long.
Sinon, au niveau IPC, je ne suis pas assez calé là dedans pour t'affirmer quoi que ce soit. Je sais juste que chez Mozilla, ils ont repris la lib IPC de chromium, avec une petite API par dessus pour que ce soit simple de communiquer entre processus via javascript.
Grosse majorité de mac, de ce que j'en ai vu, pour plusieurs raisons :
1) c'est du unix, donc on a les mêmes outils que pour linux, make, gcc et cie
2) on peut faire fonctionner les trois OS majeurs en même temps (macosx n'est pas dispo séparement), donc les developpeurs peuvent tester avec les trois OS. (ce qui n'est pas le cas sur une machine non mac.
ce n'est pas rien. Mais ce n'est pas non plus un projet de l'ampleur d'un moteur de rendu. Faut bien voir que le moteur javascript dans gecko ou webkit, n'est qu'une brique. (la preuve, on peut utiliser V8 ou tracemonkey en dehors de ces projets)
J'exagère à peine, mais l'implémentation d'un moteur JS, c'est de la gnognotte à coté de l'implémentation d'un moteur de rendu XML/HTML/CSS, avec le support de tout les standards comme DOM, HTML, SVG, et j'en passe (avec en plus dans Gecko XUL, XBL...). Chez Google et chez Mozilla, ils ont mis quelques semaines seulement à refaire un moteur JS performant qui était en état de fonctionner (je n'ai pas dit sans bug, mais un truc qui était quand même relativement opérationnel). Avoir les mêmes délais pour refaire un moteur de rendu est totalement impensable.
>Voulez-vous créer une adresse gmail? Votre adresse sera en @gmail.com
>Voulez-vous créer une adresse hotmail
Ouai, bonne idée. Ou presque. Seulement tu as oublié une chose: la pub. Aucun intérêt pour gmail ou hotmail à vouloir payer pour ça, vu que l'utilisateur ne va voir aucune pub et aucun lien l'incitant à utiliser d'autres services du provider (qui diffusent eux aussi de la pub...).
Et je doute que MozillaMessaging serait prêt à afficher de la pub explicitement dans un endroit de l'interface (comme opera le faisait dans le temps)...
> Clic droit sur un mot ou une expression dans un message: "Chercher cette expression sur Google/Yahoo/autre"
> hop, 10sec de plus...
mouai.. comment être sûr pour google que la recherche a bien été éffectué par Thunderbird ?
solution 1: thunderbird ouvre ton navigateur préféré avec l'url de recherche, et envoi en même temps sur un service web de google des données qui informe que le user a lancé la recherche. Comment être certain que le navigateur s'est bien ouvert, et que la page s'est bien affichée (avec les pubs bien entendu...) ? Thunderbird pourrait alors rajouter à l'url un parametre thunderbird=1 comme c'est fait pour firefox. Mais alors, qui rémunéré exactement ? la MoCo pour Firefox (ou Opera ou autre navigateur du user qui a déjà un contrat avec google), ou Thunderbird ?
solution 2 : thunderbird affiche directement la page web de résultat de recherche (avec toujours de la pub). Mais alors faut ajouter toutes les fonctions de navigation et de sécurité (gestion cookie, pishing et cie)... Bref, encore plus usine à gaz. Autant utiliser Seamonkey.
Bref, comme tu vois, tes propositions pondues en 10s ne sont pas si évidentes que ça.
>Cependant, verra-t-on à terme un process par onglet, comme dans Chrome ?
oui.
La version 3.7 apportera la séparation des processus pour les plugins, et la 4.0, la séparation des processus dans les onglets.
>Utiliser un thread par onglet me paraît plus pertinent, non ?
bah non. parce que tu n'a pas une séparation complète. Si il y a un crash dans un thread, c'est tout le processus qui crash (la preuve avec les crash de Firefox, qui utilisent pourtant de threads un peu partout). Mais un crash dans un processus ne fait pas crasher les autres processus (en theorie, sauf si ce crash provoque un kernel panic :-)).
Après, au niveau consommation mémoire, faut voir comment cela va être géré.
>bonjour la pollution du gestionnaire des tâches quand on ouvre une trentaine d'onglets...
personnellement, je n'ouvre le gestionnaire de taches que lorsqu'il faut que je tue un processus, c'est à dire rarement....
pardonne moi de mon ignorance, peut etre que j'ai raté un épisode, mais ce que je vois ici, http://blogs.msdn.com/ie/archive/2009/11/18/an-early-look-at(...) donc d'après des chiffres "officiels", le moteur js de IE9 est loin de mettre une branler à ces concurrences. Il rattrape juste son énorme retard, et reste encore un peu derrière ses concurrents... m'enfin on commence quand même à arriver aux limites, et je ne pense pas qu'on n'arrivera pas à grignoter plus de 20-30% sur les perfs actuels. on ne peut pas aller plus vite que ce que peuvent permettre les instructions processeurs (vu que pour arriver aux perfs actuels, le code js est transformé en instructions machines avant son execution, que ce soit dans V8 ou dans TraceMonkey, même si la manière de le faire est totalement différente).
SMIL est déjà en grande partie implémenté dans la version 3.6 qui arrive. C'est juste désactivé par défaut. (about:config chercher smil)
Et sinon, je ne sais pas si tu te rend compte de certaines choses aussi : compare par exemple la spec de SVG/SMIL, avec la spec openGL. Implémenter SVG, c'est un véritable braquage en terme de ressources humaines, tellement la spec est un pavés de plusieurs centaines de pages. Implémenter la 3D dans canvas ? c'est rien à coté de SVG, vu que des libs qui implémentant openGL existent déjà. Coté intégration donc, y "juste" à faire du mapping js <--> lib openGL, surtout qu'il ne s'agit ici que de dessiner dans une surface limité (canvas), avec aucune interaction avec le reste du document (par ex, pas de reflow sur le rendu HTML quand on dessine dans Canvas, ce qui n'est pas le cas quand il s'agit d'intégrer/modifier des bouts de svg dans le document) .
Implémenter SVG, ce n'est pas que faire appel à des primitives graphiques 2D, mais il y a aussi à implémenter son DOM, ses propriétés CSS spécifiques, son moteur de rendu, sans compter tout ce qui est timeline/synchronisme pour SMIL, et j'en passe.
Bref, comparons ce qui est comparable en terme d'implémentation. On n'est pas du tout dans la même échelle.
1) ce n'est pas implémenté par les navigateurs (ils avaient d'autres choses plus "basiques" à implementer)
2) c'était peut-être des technos à chier, trop compliquées à utiliser, ou encore pas assez riche (c'est une hypothèse, je ne les connais pas), et surtout étrangère à ceux qui font de la 3D.
3) peut être aussi un problème de puissance des machines. à l'epoque de VRML, la plupart des machines vendues n'avaient pas de carte 3D -> performances inadéquates pour faire de la 3D. alors que maintenant, toutes machines comportent une puce pour faire de la 3D.
3) il y avait d'autres chats à fouetter, le web dans son ensemble n'était peut être pas assez mature (faut voir le temps que ça a mis pour que les dev utilisent javascript correctement)
alors que bon, tout bon programmeur 3D connait openGL, ou en tout cas les principes fondamentaux de la 3D sur lesquels reposent openGL. Ils auront alors beaucoup moins de mal à "s'exprimer" sur le web qu'avec des technos underground comme VRML.
Ce n'est pas parce que un truc n'a pas marché il y a quelques années, que ça ne marchera pas maintenant, avec les évolutions technologiques tant matériels que logiciels qu'il y a eu.
Sérieusement, j'ai l'impression d'entendre un vieux refractaire à l'innovation, ou encore tim berners lee lorsqu'il fut effrayé quand il appris que Mosaic avait implémenté la balise .
> Ça répond à une volonté, stupide, d'utiliser le Web pour tout, or Internet n'est pas le Web.
Pour visualiser de la 3D sur internet, il faudrait quoi alors ? un programme à coté ? super pratique pour illustrer un document... web.
Pour lire une video, il faudrait quoi ? un programme externe ? super pratique là encore pour illustrer un document, et surtout ça donne l'impossibilité à la page web de l'intégrer dans le document, de mixer correctement la vidéo avec le reste du contenu. (ce qu'on peut faire avec la balise video et CSS/JS est tout simplement impossible avec un plugin ou l'utilisation d'un programme externe, cf demos de paul rouget)
>Mais faire des jeux vidéos, non.
et pourquoi pas ?
Très franchement, quels sont les raisons à ne pas vouloir faire en sorte qu'on puisse utiliser une plateforme commune pour jouer, lire, ou faire certaines tâches ?
Pourquoi avoir inventer javascript alors ? Pourtant il rend bien des services. Comme celui de pouvoir developper des wbemails, que certains cherissent tant et qui se demandent pourquoi les clients lourds mails existent encore.
C'est bien parce que ça rend service à une partie des utilisateurs. Qu'ils ont *besoin* de ce service.
Et bien voilà, le web evolue, parce que les besoins evoluent. les utilisations des technos changent. la manière d'utiliser internet change. Il faut donc proposer des outils, des technos, pour que cette utilisation soit plus simple, et surtout qu'il soit plus simple à développer les applications qui sont nécessaires à ces besoins.
>Faire de la messagerie instantanée, non plus, par exemple.
>je pense sincèrement que "firefox va se faire bouffer grave".
bof
>Les versions gpl et dégoogelisée de chrome vont prendre l'ascendant haut la main.
rebof
> la synchro
la synchro de quoi ?
> et les extensions sont là (y développer une extension y est simplissime en comparaison)
pareil chez Mozilla. cf jetpack.
>maintenant on va voir très vite arrivé html5, webgl, nacl et cie dans le core
comme chez Mozilla. qui n'a absolument rien à envier à chrome de ce coté là. Tout ce qui est implémenté dans chrome/webkit l'est déjà dans Mozilla ou en passe de l'être, et vice versa.
> ls vont leader l'innovation (ils le font déjà dans certain domaine : js)
js ? tracemonkey est aussi rapide voir plus rapide que V8. En tout cas, c'est kiff kiff. donc bon, pas la peine de se branler la nouille là dessus.
C'est du web. Il faut que le web evolue, parce que les développeurs ont *besoin* de fonctionnalités plus puissantes.
Peut être que tu ne vois pas l'intérêt de pouvoir utiliser openGL dans une page web, mais beaucoup le demande. Ce n'est pas pour faire du buzz. C'est vraiment pour répondre à un *besoin* : les jeux, les contenus éducatifs (pouvoir par exemple visualiser une molécule sous toute ses coutures), les contenus informatifs. ex: un site immobilier permettant de visiter les futurs appartements en 3D, ou encore la visualisation d'une collision dans un accélérateur de particules, etc.
Ce n'est pas parce que tu trouves tout ça inutile, que c'est le cas du reste du monde. L'information, ce n'est pas que du plat, du static. c'est aussi de l'interaction.
Il y a un autre avantage à implémenter des trucs "qui bouge dans tout les sens", c'est que petit à petit, ça nous permet de virer flash et consort. Et ce n'est pas rien.
Si tu veux utiliser un brouteur qui ne fais afficher que du HTML à papa, installe Mosaic.
c'est vrai, c'est chiant quoi, ils sont nuls les gens de Mozilla, ils ne peuvent pas s'occuper de tout le monde et être partout à la fois. Et ils veulent pas supporter toutes les versions de toutes les libs opensources qu'ils utilisent..
Bon et sinon, c'est quel numéro de bug ? (qu'on rigole avec toi)
Sur le site http://www.mozilla.com/, effectivement, ça ne parle principalement que de Firefox. Et pour cause : c'est le site de Mozilla Corp, la société en charge du développement de Firefox. Elle ne développe absolument pas Thunderbird. Bref, qu'elle parle seulement des produits qu'elle développe, ça ne me dérange pas outre mesure. Et c'est même tout à son honneur de presenter en page d'accueil un lien vers la société en charge du dév de Thunderbird.
La société en charge du développement de thunderbird, c'est http://www.mozillamessaging.com . Site qui ne parle tout naturellement que de Thunderbird.
Ces deux sociétés appartiennent à la fondation Mozilla. Et, Oh miracle, quand on va sur le site de la fondation, http://www.mozilla.org/ , on a bien Firefox et Thunderbird au même niveau.
euh, je n'ai pas dit 1% d'utilisateurs de firefox, mais 1% des internautes tout navigateurs confondus !
Ayant accès aux statistiques de plusieurs sites plus ou moins généraux (sans compter les rapports de xiti monitor et consort), ce n'est pas une approximation de ma part, mais un fait.
> Et puis ça fait 1 ans et demi qu'existe cette boîte, et ce n'est qu'ajourd'hui que sort Thunderbird 3.0 ? Vu qu'on parle déjà de Firefox 4.0,
Thunderbird : à peine 10 personnes à plein temps. Firefox: + de 200 personnes. À ton avis, ne serait-ce pas l'origine principale de la différence d'avancement sur les deux projets ? :-p
>non non on n'abandonne pas Thunderbird, mais bon on ne pas y mettre de l'argent non plus.
D'abord, ce n'est pas une fondation, mais une société commerciale, comme Mozilla Corp, detenues toutes les deux par la fondation Mozilla (à 100%). Ce n'est pas pour autant qu'il est simple de donner des millions comme ça. Aux dernières nouvelles, les gens employés par la MoCo, sont toujours désireuses d'avoir un salaire à la fin du mois, et aussi désireuses que la MoCo se mette des sous de coté pour pouvoir survivre si les contrats avec les moteurs de recherche n'étaient pas renouvelés (sans parler des frais divers et variés)
google ne finance pas Mozilla. Google a juste un contrat classique avec Mozilla : argent contre apport de trafic. point barre. Pareil avec les autres moteurs de recherche. Si Mozilla Corp gagne plus d'argent avec Google qu'avec les autres, c'est juste qu'il y a plus de gens utilisant Firefox + google que Firefox + yahoo.
> c'est donc une volonté d'effacer Thunderbird devant Firefox.
gniii ?? n'importe quoi. C'est juste que les moyens de Mozilla Messaging (10 personnes à tout casser ?) sont autrement plus limité que Mozilla Corp (250 personnes environ).
Faut arrêter la fumette et les théories du complot
mais c'est quoi ce FUD ?? Tu sais de quoi tu parles au moins ?
Firefox et Thunderbird sont développés par deux sociétés différentes, respectivement Mozilla Corp et Mozilla Messaging, chapotées toute les deux par la fondation Mozilla.
C'est Mozilla Corp qui gagne des sous, grâce à quelques contrats avec les moteurs de recherche (Mozilla Corp amène du trafic à ces moteurs, et en échange ceux-ci rémunèrent ce trafic apporté).
Certes, Mozilla Corp appartient à 100% à la fondation, c'est pas pour autant qu'il est possible de faire passer des millions de la Corp à Messaging (faut les payer les 250 employés de Mozilla Corp, l'infrastructure informatique et tout le toutim).
Le jour où Mozilla Messaging aura un business model lucratif, ils pourront à leur tour embaucher, développer plus vite etc.. Pour le moment ce n'est pas le cas (si tu as quelques millions à dépenser, ou une idée de business modèle permettant de gagner suffisamment, n'hésite pas à leur faire savoir).
# des reponses
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance des navigateur web: linux parent pauvre ?. Évalué à 10.
1) bon déjà, faudrait tester des navigateurs de même génération. Comparer un Chromium 4 qui vient de sortir, à une "vieille" version de Firefox, c'est limite. Car en ce moment, les progrés sont énormes ET très rapide. Bref, vaut mieux comparer avec une beta 3.6 de Firefox.
2) comme ça été dit, TraceMonkey n'est pas activé en 64bit dans la version 3.5 de Firefox, mais l'est à priori dans la version 3.6. d'où de grosse différence, puisque c'est alors l'ancien moteur JS non optimisé (SpiderMonkey) qui est utilisé
3) comme je l'ai déjà dit dans un autre commentaire, il n'y a pas de "branche" spécifique à linux ou à windows. C'est le même code, le même trunk. Les deux versions partagent au moins 90% du code, parce que l'objectif de Mozilla (depuis 1998) est justement de limiter de recoder les mêmes trucs pour chaque plateforme. Ainsi donc, c'est exactement le même moteur de rendu, le même moteur JS, la même implémentation DOM, les mêmes sources pour l'interface en XUL (modulo les fichiers CSS et quelques aménagements, comme l'emplacement de l'item de menu Options et autre trucs mineurs de cet acabi) etc..
Et tout ça repose sur une même couche d'abstraction du système, que ce soit d'un point de vue graphique (lib Cairo), ou plus général (fichiers, threads, et cie : lib NSPR)
La grosse différence entre les deux, se situe donc dans l'implémentation de cette couche d'abstraction, tant dans Cairo que NSPR, mais aussi dans le toolkit utilisé (GTK sous linux, win32 sous windows et cie)
Bref, au final, les différences de perfs entre Windows et Linux, se situent principalement dans les accés au système et à l'environnement graphique. De là à dire que le sous-systeme graphique de Windows est plus performant que X... ;-)
Notons aussi que sous linux, on a les problemes de fsync (notament via sqlite). Dans la 3.6, ils ont alors essayé de limité au maximum les accés disques et les requetes SQL, pour palier à ce défaut.
Bref, la faute n'est pas entièrement celle de Mozilla, mais de aussi des libs externes utilisées.
4) la compilation. Sous windows, c'est Visual C++ qui est utilisé. Sous les autres système, GCC. Il parait que VC produit souvent du code mieux optimisé que GCC. Ceci explique peut être cela.
D'une distro à une autre, les libs externes utilisées (sqlite et cie), ne sont pas forcément la même version qu'utilisée dans les builds windows, (qui sont celles largement testées et validées par Mozilla). Peut-être alors a-ton des différences de perfs parce qu'utilisation de libs différentes (plus ancienne par ex). Pure supposition de ma part. Notons aussi que sous windows, tout est compilé en statique.
5) possible que la différence se fait sentir à cause aussi des différences entre options de compil, entre chaque distro et os. Possible aussi que les patchs ajoutés par certaines distro aient des effets de bords..
6) reste aussi le temps passé à optimiser la version Linux. Il y a des développeurs sous linux, mais comme dit Pascalc plus haut, peu de retour, peu de beta testeur, et ne représentent même pas 1% de tout les betas testeurs. Moins de retours -> moins de bug de perf "découverts". D'ailleurs, il est probable que bon nombre de ces 1% des betas testeurs utilisent les binaires vanilla de Mozilla (compilé en static, sans patchs et autre options de compil exotiques), donc peut être avec moins de différences flagrantes. ça rejoint le point 5.
Bon, et sinon, ça râle régulièrement sur ce site, à propos des perfs sous linux (souvent à juste titre, c'est vrai). Mais râler ne suffit pas. Il faut aussi des gens pour tester et pour coder. Alors n'hésitez pas à contribuer ;-)
[^] # Re: Linux parent pauvre du fait de part de marché
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance des navigateur web: linux parent pauvre ?. Évalué à 4.
Les versions Linux et Windows partagent au moins 90% du code, et sont dans la même branche. Les seuls grosses différences, ce sont les couches basses, donc les accès au reste de l'OS (système graphique, système de fichiers etc..)
Le moteur JS, le moteur de rendu etc, tout est absolument identique.
[^] # Re: Linux parent pauvre du fait de part de marché
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Performance des navigateur web: linux parent pauvre ?. Évalué à 4.
Google n'est pas le bailleur de fond. Il n'y a qu'un simple contrat entre la MoCo et Google : argent en echange de trafic. point barre.
Mozilla peut très bien survivre sans google. Si là, maintenant, tout de suite, le contrat était rompu, Mozilla a de quoi survivre pendant 3 ans avec les mêmes dépenses. D'ailleurs, il est possible que Mozilla puisse être auto-financé avec des réductions de dépenses.
[^] # Re: bravo ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 6.
ouai enfin non, on s'en fout pas, enfin moi non. Parce que je veux que n'importe quel site puisse fonctionner correctement, surtout si il n'utilise que des standards (ou futur standards). Pour un utilisateur, surtout si il n'y connait que pouik en techno, un site qui ne fonctionne pas, c'est un site sur lequel il ne reviendra pas. Et si il tombe sur trop de site qui ne fonctionnent pas, il passe à un autre navigateur (si c'est un utilisateur un peu avancé).
>il vaut être pragmatique !
je pense que Mozilla est très pragmatique. Tiens, une preuve : acid3. ils sont pas à 100% parce qu'ils estiment qu'il y a des choses qui méritent plus d'attention, que le support des fontes SVG (les derniers points à gagner sur acid3 concernent ce support principalement). Et ils ont préférés par ex travailler sur le nouveau format WOFF (http://hacks.mozilla.org/2009/10/woff/ ), qui est un meilleur compromis entre les développeurs et les fondeurs.
>l'émulateur NES en JS (et je sais bien que ce n'est pas non plus un benchmark) tourne infiniment (100x) plus rapidement sous chrome que sous ffox.
La majorité des bottlenecks, que ce soit pour cet émulateur ou les gros sites avec plein de DHTML de partout, ce n'est pas la faute au moteur JS, tracemonkey, mais la faute à notre couche de communication DOM <-> JS.
Dans l'exécution d'une page web, il y a pleins de trucs qui entre en action, comme c'est expliqué sur http://blogs.msdn.com/ie/archive/2009/11/18/an-early-look-at(...) , faut donc pas mettre toutes les fautes sur le moteur JS.
>Ils sont arrivés "au niveau" de firefox en un an
ils n'ont, et n'auront jamais une extensibilité aussi forte que ce que permet Firefox. Ils sont au niveau en terme de navigation et visite des pages. Maintenant Chrome est loin d'être une plateforme de dev comme l'est Firefox. Faut bien voir ça. Firefox n'est pas qu'un moteur de rendu de page web. Chrome si (avec quelques boutons autour). Peut être que tu t'en fiches, que tu veux qu'un simple browser, mais Firefox n'en serait pas là où il est si il n'avait pas cette formidable extensibilité. Il (ou plutôt XulRunner, sur lequel est bati Firefox) a servi de base à plein d'appli.
>qu'ils seront, ET DE LOIN, les premiers à couvrir html5 (entre autres, pour remplacer gears, qui est une brique importante de l' "os chrome" pour l'offline) ...
euh, tout ce que fait gear, Firefox le fait depuis des lustres il me semble. Faut arreter un peu. En matière de support HTML5, chrome n'est pas si en avance, et Firefox ne prend en rien du retard. Et puis il n'y a pas que HTML5, mais aussi XBL2, et d'autres technos sur lesquels Chrome a encore du retard (à quand une implem XForms par ex, ou MathML).
>Ils ont aussi, à mon sens, un truc que mozilla n'a pas : faire plaisir à l'utilisateur final
ça c'est ton avis propre. Ce n'est pas l'avis des 330 millions d'utilisateurs de Firefox. Et aux dernières nouvelles, la progression de Chrome n'est pas si fantastique que ça, en terme de part de marché (surtout que Firefox continue à bien progresser aussi sur ce sujet). Il va falloir beaucoup de temps, à mon avis, avant que Chrome ne parviennent à rattraper Firefox.
Enfin bon, on verra...
[^] # Re: Questions...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 2.
Notons aussi que grâce aux webworkers (ff3.5), les pages web ont la possibilité de réaliser en javascript des trucs dans un thread séparé, ce qui évite les temps de "chargements" trop long.
Sinon, au niveau IPC, je ne suis pas assez calé là dedans pour t'affirmer quoi que ce soit. Je sais juste que chez Mozilla, ils ont repris la lib IPC de chromium, avec une petite API par dessus pour que ce soit simple de communiquer entre processus via javascript.
[^] # Re: Screenshots
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 2.
1) c'est du unix, donc on a les mêmes outils que pour linux, make, gcc et cie
2) on peut faire fonctionner les trois OS majeurs en même temps (macosx n'est pas dispo séparement), donc les developpeurs peuvent tester avec les trois OS. (ce qui n'est pas le cas sur une machine non mac.
Et sinon il y a aussi des devs sous linux. Et même pleins de machines de tests automatiques sous linux, qui testent et checkent en permanence les perfs de Firefox... http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox
[^] # Re: Vavavite !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Chrome disponible sous linux. Évalué à 6.
J'exagère à peine, mais l'implémentation d'un moteur JS, c'est de la gnognotte à coté de l'implémentation d'un moteur de rendu XML/HTML/CSS, avec le support de tout les standards comme DOM, HTML, SVG, et j'en passe (avec en plus dans Gecko XUL, XBL...). Chez Google et chez Mozilla, ils ont mis quelques semaines seulement à refaire un moteur JS performant qui était en état de fonctionner (je n'ai pas dit sans bug, mais un truc qui était quand même relativement opérationnel). Avoir les mêmes délais pour refaire un moteur de rendu est totalement impensable.
[^] # Re: Et bien sûr, une excellente campagne marketing autour...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 2.
>Voulez-vous créer une adresse hotmail
Ouai, bonne idée. Ou presque. Seulement tu as oublié une chose: la pub. Aucun intérêt pour gmail ou hotmail à vouloir payer pour ça, vu que l'utilisateur ne va voir aucune pub et aucun lien l'incitant à utiliser d'autres services du provider (qui diffusent eux aussi de la pub...).
Et je doute que MozillaMessaging serait prêt à afficher de la pub explicitement dans un endroit de l'interface (comme opera le faisait dans le temps)...
> Clic droit sur un mot ou une expression dans un message: "Chercher cette expression sur Google/Yahoo/autre"
> hop, 10sec de plus...
mouai.. comment être sûr pour google que la recherche a bien été éffectué par Thunderbird ?
solution 1: thunderbird ouvre ton navigateur préféré avec l'url de recherche, et envoi en même temps sur un service web de google des données qui informe que le user a lancé la recherche. Comment être certain que le navigateur s'est bien ouvert, et que la page s'est bien affichée (avec les pubs bien entendu...) ? Thunderbird pourrait alors rajouter à l'url un parametre thunderbird=1 comme c'est fait pour firefox. Mais alors, qui rémunéré exactement ? la MoCo pour Firefox (ou Opera ou autre navigateur du user qui a déjà un contrat avec google), ou Thunderbird ?
solution 2 : thunderbird affiche directement la page web de résultat de recherche (avec toujours de la pub). Mais alors faut ajouter toutes les fonctions de navigation et de sécurité (gestion cookie, pishing et cie)... Bref, encore plus usine à gaz. Autant utiliser Seamonkey.
Bref, comme tu vois, tes propositions pondues en 10s ne sont pas si évidentes que ça.
[^] # Re: Questions...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 4.
oui.
La version 3.7 apportera la séparation des processus pour les plugins, et la 4.0, la séparation des processus dans les onglets.
>Utiliser un thread par onglet me paraît plus pertinent, non ?
bah non. parce que tu n'a pas une séparation complète. Si il y a un crash dans un thread, c'est tout le processus qui crash (la preuve avec les crash de Firefox, qui utilisent pourtant de threads un peu partout). Mais un crash dans un processus ne fait pas crasher les autres processus (en theorie, sauf si ce crash provoque un kernel panic :-)).
Après, au niveau consommation mémoire, faut voir comment cela va être géré.
>bonjour la pollution du gestionnaire des tâches quand on ouvre une trentaine d'onglets...
personnellement, je n'ouvre le gestionnaire de taches que lorsqu'il faut que je tue un processus, c'est à dire rarement....
[^] # Re: bravo ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 2.
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 2.
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 8.
Et sinon, je ne sais pas si tu te rend compte de certaines choses aussi : compare par exemple la spec de SVG/SMIL, avec la spec openGL. Implémenter SVG, c'est un véritable braquage en terme de ressources humaines, tellement la spec est un pavés de plusieurs centaines de pages. Implémenter la 3D dans canvas ? c'est rien à coté de SVG, vu que des libs qui implémentant openGL existent déjà. Coté intégration donc, y "juste" à faire du mapping js <--> lib openGL, surtout qu'il ne s'agit ici que de dessiner dans une surface limité (canvas), avec aucune interaction avec le reste du document (par ex, pas de reflow sur le rendu HTML quand on dessine dans Canvas, ce qui n'est pas le cas quand il s'agit d'intégrer/modifier des bouts de svg dans le document) .
Implémenter SVG, ce n'est pas que faire appel à des primitives graphiques 2D, mais il y a aussi à implémenter son DOM, ses propriétés CSS spécifiques, son moteur de rendu, sans compter tout ce qui est timeline/synchronisme pour SMIL, et j'en passe.
Bref, comparons ce qui est comparable en terme d'implémentation. On n'est pas du tout dans la même échelle.
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 3.
C'est pas utilisé parce que :
1) ce n'est pas implémenté par les navigateurs (ils avaient d'autres choses plus "basiques" à implementer)
2) c'était peut-être des technos à chier, trop compliquées à utiliser, ou encore pas assez riche (c'est une hypothèse, je ne les connais pas), et surtout étrangère à ceux qui font de la 3D.
3) peut être aussi un problème de puissance des machines. à l'epoque de VRML, la plupart des machines vendues n'avaient pas de carte 3D -> performances inadéquates pour faire de la 3D. alors que maintenant, toutes machines comportent une puce pour faire de la 3D.
3) il y avait d'autres chats à fouetter, le web dans son ensemble n'était peut être pas assez mature (faut voir le temps que ça a mis pour que les dev utilisent javascript correctement)
alors que bon, tout bon programmeur 3D connait openGL, ou en tout cas les principes fondamentaux de la 3D sur lesquels reposent openGL. Ils auront alors beaucoup moins de mal à "s'exprimer" sur le web qu'avec des technos underground comme VRML.
Ce n'est pas parce que un truc n'a pas marché il y a quelques années, que ça ne marchera pas maintenant, avec les évolutions technologiques tant matériels que logiciels qu'il y a eu.
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 2.
> Ça répond à une volonté, stupide, d'utiliser le Web pour tout, or Internet n'est pas le Web.
Pour visualiser de la 3D sur internet, il faudrait quoi alors ? un programme à coté ? super pratique pour illustrer un document... web.
Pour lire une video, il faudrait quoi ? un programme externe ? super pratique là encore pour illustrer un document, et surtout ça donne l'impossibilité à la page web de l'intégrer dans le document, de mixer correctement la vidéo avec le reste du contenu. (ce qu'on peut faire avec la balise video et CSS/JS est tout simplement impossible avec un plugin ou l'utilisation d'un programme externe, cf demos de paul rouget)
>Mais faire des jeux vidéos, non.
et pourquoi pas ?
Très franchement, quels sont les raisons à ne pas vouloir faire en sorte qu'on puisse utiliser une plateforme commune pour jouer, lire, ou faire certaines tâches ?
Pourquoi avoir inventer javascript alors ? Pourtant il rend bien des services. Comme celui de pouvoir developper des wbemails, que certains cherissent tant et qui se demandent pourquoi les clients lourds mails existent encore.
C'est bien parce que ça rend service à une partie des utilisateurs. Qu'ils ont *besoin* de ce service.
Et bien voilà, le web evolue, parce que les besoins evoluent. les utilisations des technos changent. la manière d'utiliser internet change. Il faut donc proposer des outils, des technos, pour que cette utilisation soit plus simple, et surtout qu'il soit plus simple à développer les applications qui sont nécessaires à ces besoins.
>Faire de la messagerie instantanée, non plus, par exemple.
qui a parlé de messagerie instantanée ?
[^] # Re: bravo ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 5.
bof
>Les versions gpl et dégoogelisée de chrome vont prendre l'ascendant haut la main.
rebof
> la synchro
la synchro de quoi ?
> et les extensions sont là (y développer une extension y est simplissime en comparaison)
pareil chez Mozilla. cf jetpack.
>maintenant on va voir très vite arrivé html5, webgl, nacl et cie dans le core
comme chez Mozilla. qui n'a absolument rien à envier à chrome de ce coté là. Tout ce qui est implémenté dans chrome/webkit l'est déjà dans Mozilla ou en passe de l'être, et vice versa.
> ls vont leader l'innovation (ils le font déjà dans certain domaine : js)
js ? tracemonkey est aussi rapide voir plus rapide que V8. En tout cas, c'est kiff kiff. donc bon, pas la peine de se branler la nouille là dessus.
[^] # Re: La troidé sous X.Org
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Des news de Firefox. Évalué à 3.
Peut être que tu ne vois pas l'intérêt de pouvoir utiliser openGL dans une page web, mais beaucoup le demande. Ce n'est pas pour faire du buzz. C'est vraiment pour répondre à un *besoin* : les jeux, les contenus éducatifs (pouvoir par exemple visualiser une molécule sous toute ses coutures), les contenus informatifs. ex: un site immobilier permettant de visiter les futurs appartements en 3D, ou encore la visualisation d'une collision dans un accélérateur de particules, etc.
Ce n'est pas parce que tu trouves tout ça inutile, que c'est le cas du reste du monde. L'information, ce n'est pas que du plat, du static. c'est aussi de l'interaction.
Il y a un autre avantage à implémenter des trucs "qui bouge dans tout les sens", c'est que petit à petit, ça nous permet de virer flash et consort. Et ce n'est pas rien.
Si tu veux utiliser un brouteur qui ne fais afficher que du HTML à papa, installe Mosaic.
[^] # Re: Screenshots
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 1.
[^] # Re: >
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 4.
Bon et sinon, c'est quel numéro de bug ? (qu'on rigole avec toi)
[^] # Re: Qui se sert encore des clients lourds ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Thunderbird 3.0 est sorti. Évalué à 10.
Je suppose que je ne suis pas le seul.
[^] # Re: Et bien sûr, une excellente campagne marketing autour...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 6.
Sur le site http://www.mozilla.com/, effectivement, ça ne parle principalement que de Firefox. Et pour cause : c'est le site de Mozilla Corp, la société en charge du développement de Firefox. Elle ne développe absolument pas Thunderbird. Bref, qu'elle parle seulement des produits qu'elle développe, ça ne me dérange pas outre mesure. Et c'est même tout à son honneur de presenter en page d'accueil un lien vers la société en charge du dév de Thunderbird.
La société en charge du développement de thunderbird, c'est http://www.mozillamessaging.com . Site qui ne parle tout naturellement que de Thunderbird.
Ces deux sociétés appartiennent à la fondation Mozilla. Et, Oh miracle, quand on va sur le site de la fondation, http://www.mozilla.org/ , on a bien Firefox et Thunderbird au même niveau.
vala vala.
[^] # Re: >
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 2.
Ayant accès aux statistiques de plusieurs sites plus ou moins généraux (sans compter les rapports de xiti monitor et consort), ce n'est pas une approximation de ma part, mais un fait.
[^] # Re: Et bien sûr, une excellente campagne marketing autour...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 3.
Thunderbird : à peine 10 personnes à plein temps. Firefox: + de 200 personnes. À ton avis, ne serait-ce pas l'origine principale de la différence d'avancement sur les deux projets ? :-p
>non non on n'abandonne pas Thunderbird, mais bon on ne pas y mettre de l'argent non plus.
D'abord, ce n'est pas une fondation, mais une société commerciale, comme Mozilla Corp, detenues toutes les deux par la fondation Mozilla (à 100%). Ce n'est pas pour autant qu'il est simple de donner des millions comme ça. Aux dernières nouvelles, les gens employés par la MoCo, sont toujours désireuses d'avoir un salaire à la fin du mois, et aussi désireuses que la MoCo se mette des sous de coté pour pouvoir survivre si les contrats avec les moteurs de recherche n'étaient pas renouvelés (sans parler des frais divers et variés)
[^] # Re: Une liste de nouveautés un peu plus complète...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 3.
[^] # Re: Et bien sûr, une excellente campagne marketing autour...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 2.
gniii ?? n'importe quoi. C'est juste que les moyens de Mozilla Messaging (10 personnes à tout casser ?) sont autrement plus limité que Mozilla Corp (250 personnes environ).
Faut arrêter la fumette et les théories du complot
[^] # Re: Et bien sûr, une excellente campagne marketing autour...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird 3 est dehors. Évalué à 3.
Firefox et Thunderbird sont développés par deux sociétés différentes, respectivement Mozilla Corp et Mozilla Messaging, chapotées toute les deux par la fondation Mozilla.
C'est Mozilla Corp qui gagne des sous, grâce à quelques contrats avec les moteurs de recherche (Mozilla Corp amène du trafic à ces moteurs, et en échange ceux-ci rémunèrent ce trafic apporté).
Certes, Mozilla Corp appartient à 100% à la fondation, c'est pas pour autant qu'il est possible de faire passer des millions de la Corp à Messaging (faut les payer les 250 employés de Mozilla Corp, l'infrastructure informatique et tout le toutim).
Le jour où Mozilla Messaging aura un business model lucratif, ils pourront à leur tour embaucher, développer plus vite etc.. Pour le moment ce n'est pas le cas (si tu as quelques millions à dépenser, ou une idée de business modèle permettant de gagner suffisamment, n'hésite pas à leur faire savoir).