Ça veut rien dire. Les sites de nos jours sont gourmands.
Si mon gmail prend plus de memoire que mon claws-mail, ca veut dire quelque chose !
Je trouve bizarre de parier sur quelque chose dont tu ne connais rien : le matos qui sera utilisé, la pile graphique utilisée, le fonctionnement du moteur de rendu etc..
J'ai suffisament d'experience sur comment optimiser un pipeline de rendu graphique et sur le materiel disponible pour les constructeurs de telephone pour estimer pouvoir prendre ce parie. J'ai une idee assez precise de ce qu'on peut avoir et pour quel prix. Il y aura forcement draw back a leur choix.
Je ne comprend pas de quoi tu parles là… Le rendu graphique n'est pas en JS. De plus y a du JIT dans le moteur JS de Firefox…
Encore heureux que le rendu graphique ne soit pas en JS ! Mais si tu as un jour code un pipeline graphique, tu saurais que la plus grande difficulte est dans le scene graph qui est en charge de gerer les requetes au code de rendu direct. Ce code la est massivement code en JS (exemple le petit lien plus haut sur facebook…). Et le JIT ne t'aidera pas beaucoup par rapport a du natif, car tu as un certain nombre d'optimisation impossible du fait de l'impossibilite de manipuler la memoire directement. Cela bien entendu en partant du principe que ton JIT et ton toolkit JS se comprenne bien…
Ce n'est pas un domaine trivial que de reussir a optimiser ton code non type sans gestion de la memoire pour qu'il soit proche en terme de vitesse de ce qu'on fait en natif de maniere naive. Et tout comme le Java pendant la derniere decennie, le JS, dont le JIT est fait au runtime, sera forcement toujours plus lent que du code natif au petit oignon. Et oui, les toolkits natifs font de gros effort sur ces morceaux de code.
[^] # Re: sans intérêt
Posté par cedric . En réponse au journal Ubuntu phone OS. Évalué à 3.
Si mon gmail prend plus de memoire que mon claws-mail, ca veut dire quelque chose !
J'ai suffisament d'experience sur comment optimiser un pipeline de rendu graphique et sur le materiel disponible pour les constructeurs de telephone pour estimer pouvoir prendre ce parie. J'ai une idee assez precise de ce qu'on peut avoir et pour quel prix. Il y aura forcement draw back a leur choix.
Encore heureux que le rendu graphique ne soit pas en JS ! Mais si tu as un jour code un pipeline graphique, tu saurais que la plus grande difficulte est dans le scene graph qui est en charge de gerer les requetes au code de rendu direct. Ce code la est massivement code en JS (exemple le petit lien plus haut sur facebook…). Et le JIT ne t'aidera pas beaucoup par rapport a du natif, car tu as un certain nombre d'optimisation impossible du fait de l'impossibilite de manipuler la memoire directement. Cela bien entendu en partant du principe que ton JIT et ton toolkit JS se comprenne bien…
Ce n'est pas un domaine trivial que de reussir a optimiser ton code non type sans gestion de la memoire pour qu'il soit proche en terme de vitesse de ce qu'on fait en natif de maniere naive. Et tout comme le Java pendant la derniere decennie, le JS, dont le JIT est fait au runtime, sera forcement toujours plus lent que du code natif au petit oignon. Et oui, les toolkits natifs font de gros effort sur ces morceaux de code.