Chrome : Ignition doit réduire la consommation de mémoire vive autour de JavaScript

Bon, de 5 % dans un premier temps

Le 30 août 2016 à 10h10

3 min

Logiciel

Durant la conférence BlinkOn, Google a présenté un nouvel interpréteur JavaScript pour Chrome. Baptisé Ignition, il aura dans un premier temps la mission de réduire la consommation de mémoire vive, particulièrement sur les appareils mobiles.

Le JavaScript, comme tout langage de script, est interprété ou compilé. Contrairement à un exécutable binaire qui peut être exécuté directement, il doit d’abord être traduit en langage machine. C’est le travail du compilateur JavaScript à la volée (just-in-time), qui permet de générer de l’assembleur avant de l’envoyer pour traitement au processeur.

Dans la machine virtuelle JavaScript V8 de Chrome, ce compilateur est basique : il doit avant tout générer un code machine aussi rapidement que possible. Cette phase, dont la durée doit être minimale, a l’inconvénient de pouvoir consommer une grande quantité de mémoire vive, même quand le code n’est exécuté qu’une fois. Ledit code circule en fait dans un pipeline d’exécution, qui permet en fonction de ce qui y est détecté de passer le relai à deux autres compilateurs, optimisés ceux-là : Crankshaft et TurboFan.

Ignition simplifie le pipeline d'exécution

Arrive Ignition. Il s’agit d’un nouvel interpréteur de JavaScript, qui peut se substituer au compilateur de base en début de pipeline de V8. L’intérêt d’Ignition est double selon Google : simplifier la chaine d’exécution et procéder à une compilation moins gourmande en mémoire vive. Pour ce faire, Ignition applique une recette connue : le script compilé est transformé en bytecode, un code « prémaché » dont le poids ne représente plus que la moitié, voire le quart de celui d’un code compilé basique.

google chrome ignition

Le bytecode passe ensuite à la moulinette d’un autre interpréteur, conçu pour cette opération. Le résultat dispose des optimisations spécifiques à la plateforme matérielle détectée. Google n’a pas réinventé la roue : l’éditeur a tout simplement réutilisé les instructions macro-assembleur de TurboFan pour concevoir Ignition. Il fournit donc au compilateur final un code équipé de tous les « marqueurs » nécessaires pour une architecture donnée.

Uniquement pour Android sur de petits appareils pour l'instant

Ignition devra cependant attendre pour révéler son plein potentiel. Il ne sera actif dans un premier temps que dans la version Android de Chrome, et uniquement pour des appareils qui disposent de 512 Mo de mémoire vive ou moins. D’après les tests réalisés par Google, la consommation en mémoire diminue d’environ 5 % sur chaque onglet.

Ross McIlroy, qui en gère le développement, indique cependant qu’Ignition offre d’autres possibilités, notamment de pouvoir « prendre de meilleures décisions » sur le bon moment pour exécuter et optimiser le code, grâce à la simplification du pipeline. Ceux qui souhaitent en savoir davantage sur Ignition pourront lire la présentation réalisée par Google.

Commentaires (71)

_Quentin_

Le 30/08/2016 à 10h14

J’ai rien compris, mais ça a l’air vachement chiadé " />

megabigbug

Le 31/08/2016 à 06h54

flamaros a écrit :

Moi j’aimerais bien du QML (Qt Quick) plutôt que le html.

Pareil. Il y a tellement d’éléments dynamiques dans une page web qui pourraient être codées de façon déclarative sans avoir recours à du javascript. Et je ne parle pas du système de placement des éléments du html/css qui a été conçu pour représenter des documents et qui est inadapté à la conception d’UI.

 

Si tu es intéressé, il y a des développeurs qui ont utilisés emscripten pour transformer le moteur qtquick en javascript:

démo qt quick dans un navigateur

C’est complètement expérimental, mais c’est quand même une belle prouesse d’avoir transpilé en javascript le moteur javascript de chrome utilisé par qtquick et le faire exécuter par le moteur javascript de chrome " />

brazomyna

Le 31/08/2016 à 07h03

megabigbug a écrit :

Pareil. Il y a tellement d’éléments dynamiques dans une page web qui pourraient être codées de façon déclarative sans avoir recours à du javascript.

Un peu comme le fait CSS3, quoi.

 

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 31/08/2016 à 07h48

Ou alors, peut-être, existe-t-il des gens qui constatent que le modèle objet de JavaScript - où chaque objet n’est qu’une collection de propriétés nommées - est bien adapté syntaxiquement à la représentation compacte d’un élément du DOM dans une expression (vu que c’est à ça qu’il était destiné), mais à-peu-près rien d’autre ?

Ou alors qu’il existe des gens qui s’émeuvent que ce langage, hégémonique dans les browsers car bien adapté à la manipulation du DOM, est poussé dans des applications où il est largement sorti de son domaine de compétences pour l’unique raison que “comme ça vous pouvez utiliser le langage que vous connaissez déjà” ?

t0FF

Le 31/08/2016 à 07h49

Ah ouai quand même ! 

Chez moi c’est pas le premier : aucun processus chrome ne prend plus de 100mo de mémoire (j’ai 8 onglets d’ouvert, dont gmail). 

Au dessus j’ai sql développeur, firefox (2 onglets dont une boite mail) et en tête de liste j’ai mon zend-eclipse à 400mo ! (13 projets, 4 fichiers ouverts). 

 

anonyme_b3e05f43bed326da32611ec4ad59c217

Le 31/08/2016 à 07h55

blackdream a écrit :

Ah ouai quand même !

Chez moi c’est pas le premier : aucun processus chrome ne prend plus de 100mo de mémoire (j’ai 8 onglets d’ouvert, dont gmail).

Au dessus j’ai sql développeur, firefox (2 onglets dont une boite mail) et en tête de liste j’ai mon zend-eclipse à 400mo ! (13 projets, 4 fichiers ouverts).

C’est l’éternel problème : à chaque news, il y a des comparaisons de conso mémoire entre INpactiens, mais sans protocole précis. Tout dépend des pages ouvertes, de leur contenu, de la navigation effectuée, etc.

Pour être précis, il faudrait simplement un jour que quelqu’un fasse le même test avec les mêmes pages sur 2 navigateurs d’un même PC.

skan

Le 31/08/2016 à 08h24

Natürlisch! ;)

t0FF

Le 31/08/2016 à 08h35

Bah là c’était surtout pour comparer la conso de gmail, mais c’est vrai que même sur une seule page il y a plein d’autre choses qui peuvent influencer (plugins, os, version de chrome etc). 

nekogami

Le 31/08/2016 à 09h10

2 mots: left-pad :p (bon ok non seulement c’est du troll mais en plus c’est en NodeJS)

Sinon le problème vient en partie je pense de l’héritage que le langage doit supporter et qui peu paraître pas super propre (api de base bordélique dans certains cas, le fait de pas avoir les types de base classique genre Number etc etc).

Dans tous les cas j’attends les WebAssembly avec impatience " /> (ouai je sais, je peux toujours attendre)

damaki Abonné

Le 31/08/2016 à 12h21

Oui, mais Babel le supporte déjà dans une certaine mesure. Et vu que Babel est quasi obligatoire pour la compatibilité et les polyfills d’IE, autant y aller à fond et utiliser ES7.

damaki Abonné

Le 31/08/2016 à 12h22

J’ai commencé les hostilités et je m’en excuse. C’était juste à titre indicatif.

Et soit dit en passsant, pour Chrome, c’est pas évident de calculer son utilisation mémoire réelle à cause des process séparés et de la mémoire partagée.

anonyme_b3e05f43bed326da32611ec4ad59c217

Le 31/08/2016 à 12h29

damaki a écrit :

J’ai commencé les hostilités et je m’en excuse. C’était juste à titre indicatif.

Et soit dit en passsant, pour Chrome, c’est pas évident de calculer son utilisation mémoire réelle à cause des process séparés et de la mémoire partagée.

Y a pas de souci, ça reste très courtois :)

flamaros

Le 31/08/2016 à 15h02

megabigbug a écrit :

Pareil. Il y a tellement d’éléments dynamiques dans une page web qui pourraient être codées de façon déclarative sans avoir recours à du javascript. Et je ne parle pas du système de placement des éléments du html/css qui a été conçu pour représenter des documents et qui est inadapté à la conception d’UI.
&nbsp;      


Si tu es intéressé, il y a des développeurs qui ont utilisés emscripten pour transformer le moteur qtquick en javascript:      
démo qt quick dans un navigateur
C'est complètement expérimental, mais c'est quand même une belle prouesse d'avoir transpilé en javascript le moteur javascript de chrome utilisé par qtquick et le faire exécuter par le moteur javascript de chrome 
Oui je connais le port javascript de QtQuick , mais idéale serait que le scene graph QML soit directement intégré dans les navigateurs, c’est tellement plus performant pour le rendu que le html/css qui est extrêmement complexe pour le positionnement,… D’ailleurs pendant des années les différents moteurs de rendu html avaient des présentations différentes des mêmes pages.

En QtQuick au moins c’est l’utilisateur qui défini les règles de rendu, le moteur ne s’occupant que d’appliquer des simples transformations sur une hiérarchie d’éléments.

Et le fait que le QML soit déjà un dérivé du JS faciliterait l’adoption.

J’arrive pas à me mettre au html car c’est l’enfer quand on débute de régler la mise en page surtout si on veux en plus gérer le resize qui s’adapte à l’écran.

lossendae

Le 31/08/2016 à 16h56

Ca doit dependre de ta formation.

Je trouve le couple HTML + CSS tres simple à utiliser.

Et honnêtement, faire du style en JS, c’est à vomir… du moins pour le peu que j’ai essayé avec react + jsx.

megabigbug

Le 31/08/2016 à 20h08

brazomyna a écrit :

Un peu comme le fait CSS3, quoi.

 

Non, le CSS3 ne permet pas de faire ce que fait QML.

Par exemple, tu ne peux pas de façon déclarative dire que la largeur d’un rectangle est égale à sa hauteur pour en faire un carré. En QML, un tel carré resterait carré si sa largeur change au cours du temps.

Dans le même genre, en HTML/CSS c’est très compliqué de dire qu’un rectangle à son bord gauche à droite d’un premier élément et son bord droit à gauche d’un second élément et de faire en sorte que lorsque les deux éléments se rapprochent ou s’éloignent le rectangle continue à prendre l’espace entre les deux éléments.

C’est possible de s’en sortir maintenant avec des flexbox mais c’est quand même la misère à déclarer par rapport à QML. Il faut notamment déclarer le comportement d’un élément sur son conteneur et non sur l’élément lui même et du coup on est obligé d’avoir un élément conteneur qui souvent ne sert qu’à la mise en forme.

 

brazomyna

Le 31/08/2016 à 20h16

megabigbug a écrit :

Non, le CSS3 ne permet pas de faire ce que fait QML.

Pour connaître les deux domaines il me paraît plus que probable que tu aies une bonne expérience en matière de création d’UI et une expérience quasi inexistante en matière de conception web.

C’est flagrant: l’ensemble de tes raisonnement se fondent sur les principes et les besoins relatifs à la création de ce que tu connais: les UI.
Sauf que HTML/CSS c'est pas pour faire des UI pour des applications ; c'est fait pour faire ... des pages web. Or les pages web ont un contenu dont la nature est différente, un objectif différent, dont les terminaux, leur diversité, leurs interactions sont différents, etc...      
En gros tu ressembles à un charpentier qui plante des clous toute la journée. Et ne jure que par les marteaux comme 'outil ultime'. Et tu nous expliques que les mécaniciens ont tort d'utiliser des tournevis pour leur tâches, parce qu'un marteau c'est quand même vachement mieux pour planter des clous.

megabigbug

Le 31/08/2016 à 20h28

brazomyna a écrit :

En gros tu ressembles à un charpentier qui ne jure que par les marteaux comme ‘outil ultime’. Et tu nous expliques que les mécaniciens ont tort d’utiliser des tournevis pour leur tâches, parce qu’un marteau c’est quand même vachement mieux pour planter des clous.

Justement, aujourd’hui, les mécaniciens se mettent tous à planter des clous (font des UI d’applications avec des technos web) et passent de moins en moins de temps à serrer des vis (créer du contenu web).

Au vu de cette tendance, c’est normale que je fasse la remarque qu’ils n’utilisent pas le bon outil.

Zulgrib Abonné

Le 30/08/2016 à 11h43

J’aime ton idée

WereWindle

Le 30/08/2016 à 11h51

brazomyna a écrit :

Allez, soyons fous …

Je propose un couple de deux technos complémentaires, l’une pour le contenu sous forme structurée ; l’autre pour la représentation graphique.

Appelons les HTML pour le premier et CSS pour le second.

mais tu es un grand malade toi !! c’est complètement insensé cette approche " />

skan

Le 30/08/2016 à 12h06

«Java is to JavaScript as car is to carpet»

John Shaft

Le 30/08/2016 à 12h22

Y a pas de quoi mettre le feu aux poudres.

–> [] " />

damaki Abonné

Le 30/08/2016 à 12h25

So 2015. On en est à ecmascript 7 depuis juin. " />

damaki Abonné

Le 30/08/2016 à 12h29

Firefox fait largement mieux et se bonifie avec le temps en conso mémoire, malgré le bad buzz qui lui colle à la peau. Ici, 26 onglets, 433 Mo en x86.

[edit:]En chargeant pour de vrai les 26 onglets, c’est 802 Mo, ce qui reste honorable.

v1nce

Le 30/08/2016 à 12h33

ouais du xml et du xsl quoi

jaretlafoudre

Le 30/08/2016 à 12h43

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

En gros, ils proposent que les développeurs fabriquent à partir de leur sources Javascript un fichier contenant du bytecode (avec l’extension .class) qu’ils compressent dans un fichier zip auquel ils donnent l’extension .jar

" />

 " />" />

 " />" />" />

Mais non, en fait maintenant qu’on a éliminé le flash dans les pages web pour le remplacer par du javascript, on s’aperçoit que finalement c’est pas mieux, et même souvent pire, du coup on refais du flash sauce javascript…

flamaros

Le 30/08/2016 à 12h43

Moi j’aimerais bien du QML (Qt Quick) plutôt que le html.

psn00ps

Le 30/08/2016 à 12h45

t’as vu les 5 trolls ? " />

wanou2

Le 30/08/2016 à 12h57

damaki a écrit :

Firefox fait largement mieux et se bonifie avec le temps en conso mémoire, malgré le bad buzz qui lui colle à la peau. Ici, 26 onglets, 433 Mo en x86.

[edit:]En chargeant pour de vrai les 26 onglets, c’est 802 Mo, ce qui reste honorable.

Faut arrêter un peu avec ça, on a complètement déchargé les serveurs au profit des clients. 26 pages affichés  pour 802 Mo c’est énorme : une consommation de 30Mo par page pour du texte des images…

2show7

Le 30/08/2016 à 12h58

Bond, de 5% ….. c’est bon aussi ?

brazomyna

Le 30/08/2016 à 13h22

wanou2 a écrit :

une consommation de 30Mo par page pour du texte des images…

Pour moi c’est au contraire que dalle.

Tu prends la présente page de NextInpact, tu la sauvegardes avec l’ensemble des fichiers de ressources attachés, tu récupères déjà plus de 3Mo d’images en tout genre, toutes compressées au maximum.

Tu prends rien que ces images, tu les mets en mémoire dans un format non compressé, tu as facile un facteur 5 ou 10 de mémoire

 

Tu as même pas commencé à allouer un peu de mémoire pour le JS à exécuter ; pas encore de RAM pour mettre un minimum quelques rendus partiels de la page en cache, rien sur toutes les métadonnées des différents éléments, etc… et tu as déjà bouffé tes 30Mo.

 

Tu voudrais quoi ? De la magie ?

 

le-gros-bug

Le 30/08/2016 à 13h29

 Chrome sur un phone avec 512mo il y a du boulot…

T’ouvre n’importe quel site ça balance un low memory" />

wanou2

Le 30/08/2016 à 13h36

brazomyna a écrit :

Pour moi c’est au contraire que dalle.

Tu prends la présente page de NextInpact, tu la sauvegardes avec l’ensemble des fichiers de ressources attachés, tu récupères déjà plus de 3Mo d’images en tout genre, toutes compressées au maximum.

Tu prends rien que ces images, tu les mets en mémoire dans un format non compressé, tu as facile un facteur 5 ou 10 de mémoire

 

Tu as même pas commencé à allouer un peu de mémoire pour le JS à exécuter ; pas encore de RAM pour mettre un minimum quelques rendus partiels de la page en cache, rien sur toutes les métadonnées des différents éléments, etc… et tu as déjà bouffé tes 30Mo.

 

Tu voudrais quoi ? De la magie ?

 

Mouais… il y a 10 ans les machines avait des puissances et surtout des quantités de mémoire largement inférieur à aujourd’hui. Les sites n’était pas beaucoup moins beau qu’actuellement et les consommations mémoires très inférieur. Je n’y connais rien mais j’ai quand même l’impression d’un gâchis de ressource dans le domaine plutôt qu’autre chose !

Mais bon tu as sans doute raison, il est normal de bouffer plus de 140 Mo pour afficher une page (le navigateur (chromium) + cette page sur ma machine…)

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 30/08/2016 à 13h40

psn00ps a écrit :

t’as vu les 5 trolls ? " />

Six, en fait " />

brazomyna

Le 30/08/2016 à 13h47

wanou2 a écrit :

Mouais… il y a 10 ans les machines avait des puissances et surtout des quantités de mémoire largement inférieur à aujourd’hui. Les sites n’était pas beaucoup moins beau qu’actuellement et les consommations mémoires très inférieur. Je n’y connais rien mais j’ai quand même l’impression d’un gâchis de ressource dans le domaine plutôt qu’autre chose !

Il y a 10 ans, une page web c’était des images 10 fois moins grosses, des résolutions 4 fois inférieures, etc…

Non, c’était “pas exactement” la même chose que maintenant.

wanou2 a écrit :

  plus de 140 Mo pour afficher une page (le navigateur (chromium) + cette page sur ma machine…)

Non, mais tu devrais aussi ajouter la mémoire prise par l’OS aussi, pour avoir une analyse encore plus fine.

Bordel, 1Go pour afficher une page web " />

 

wanou2

Le 30/08/2016 à 13h51

brazomyna a écrit :

Il y a 10 ans, une page web c’était des images 10 fois moins grosses, des résolutions 4 fois inférieures, etc…

Non, c’était “pas exactement” la même chose que maintenant.

Le problème c’est que maintenant mon ordi a une résolution de 1366768 alors qu’il y a 10 ans mon ordi avait une résolution de 1280800 alors moi je vois la même chose " />

wanou2

Le 30/08/2016 à 13h59

brazomyna a écrit :

Bordel, 1Go pour afficher une page web " />

 

Sur 1006 Mo actuellement consommé 441 Mo sont consommés pour cette page web sur firefox " />

WereWindle

Le 30/08/2016 à 14h07

wanou2 a écrit :

Sur 1006 Mo actuellement consommé 441 Mo sont consommés pour cette page web sur firefox " />

le poids des mots, tout ça tout ça " />

brazomyna

Le 30/08/2016 à 14h23

WereWindle a écrit :

le poids des mots, tout ça tout ça " />

 Tu savais que, une fois décompressée en mémoire, ton avatar pesait plus de 100ko dans ma ptite RAM ?

 

IN-AD-MIS-SIBLE !!! " />

Patch Abonné

Le 30/08/2016 à 14h34

brazomyna a écrit :

Tu savais que, une fois décompressée en mémoire, ton avatar pesait plus de 100ko dans ma ptite RAM ?

IN-AD-MIS-SIBLE !!! " />

Le poids des mots de son avatar… " />

t0FF

Le 30/08/2016 à 14h34

Tu confond beauté et ergonomie. 

Oui il y a 10 ans les pages n’étaient pas tellement moins belles (enfin c’est très relatif). Une image peut être belle, ce n’est pas la question. 

Aujourd’hui tu peux interagir avec la plupart des éléments d’une page, sans avoir un rafraîchissement. 

Et comme tu le dis, la définition d’écran a été multiplié par 4, et le poids des images à plus ou moins suivit. 

Il y a 10 ans, il n’y avait aucun plugin, aujourd’hui la plupart des visiteurs ont au moins 3 plugin accroché au navigateur, souvent plus. 

Il y a 10 ans il n’y avait pas ou peu de trackers, aujourd’hui rare sont les sites qui en ont moins de 5. 

Il y a 10 ans, la sécurité des navigateurs était nulle, aujourd’hui il y a des tas de mécanismes de sécurité, qui prennent forcément de la ram. 

Il y a 10 ans, les navigateurs ne savaient lire que des pages web. Aujourd’hui ils sont capable d’ouvrir de nombreux types de documents. 

Aujourd’hui les sites internet ont des interfaces aussi riche voir plus riche que la plupart des logiciels d’il y a 10 ans. 

Pour ce que tu dis sur le fait de décharger les serveurs vers les clients, c’est un peu vrai. Mais ce que tu perds en ram, tu le gagnes en fluidité, car faire des aller-retours entre le client et le serveur rend l’expérience de navigation très désagréable. 

Plusieurs sites proposent des versions sans javascripts (gmail par exemple), mais c’est très désagréable à utiliser. A coté de ça, le prix de la mémoire vive a beaucoup baissé. Donc je ne vois pas pour qu’elle raison il faudrait revenir à l’internet d’il y a 10 ans.  

brazomyna

Le 30/08/2016 à 14h43

Patch a écrit :

Le poids des mots de son avatar… " />

Ok, va. Je valide. " />

 

wanou2

Le 30/08/2016 à 15h53

blackdream a écrit :

Plusieurs sites proposent des versions sans javascripts (gmail par exemple), mais c’est très désagréable à utiliser.

C’est cette version que j’utilise parce que je trouve la version “normale” trop lourde. En html, c’est hyper efficace (à mon goût), plus rapide à charger (je clique ça affiche dans la seconde), j’ai pas de machin chat contact qui s’affiche à chaque fois que je bouge ma souris, je ne clique pas par erreur sur un bouton parce qu’un truc s’est chargé entre temps, …

 En fait… je suis un vieux con anti-progrès :‘(

t0FF

Le 30/08/2016 à 17h57

Bah… ouai " />

La version allégée peut avoir de l’intérêt sur un vieille ordinateur, mais elle enlève des fonctionnalités sympa je trouve. Et puis j’ai pas l’impression que la version complète est si lourde que ça, mais bon les ordinateurs que j’utilise ont tous 4go ou plus.  

wanou2

Le 30/08/2016 à 18h09

blackdream a écrit :

Bah… ouai " />

La version allégée peut avoir de l’intérêt sur un vieille ordinateur, mais elle enlève des fonctionnalités sympa je trouve. Et puis j’ai pas l’impression que la version complète est si lourde que ça, mais bon les ordinateurs que j’utilise ont tous 4go ou plus.  

Moi c’est un vieux celeron n2840 avec 2 Go de ram. Sous nunux ça passe sous win10 ça rame sévère !

CNek

Le 30/08/2016 à 20h36

Faut qu’on m’explique cette haine courante pour le JS, avant c’était PHP qui prenait le plus cher, il est en passe d’être détrôné " />

CreaYouz

Le 30/08/2016 à 21h11

Bah si le navigateur fait le job et que j’ai plus à optimiser chaque bout de code ou d’image je m’en porterai pas plus mal /troll

lossendae

Le 30/08/2016 à 22h46

Le 6 n’est même pas encore entierement supporté par tous les navigateurs. On a de quoi voir venir pour le 7…

brazomyna

Le 31/08/2016 à 05h23

CNek a écrit :

Faut qu’on m’explique cette haine courante pour le JS, avant c’était PHP qui prenait le plus cher, il est en passe d’être détrôné " />

Chez les développeurs c’est comme partout: tu auras toujours une proportion de gugus incapables de dépasser le raisonnement d’un enfant de 5 ans.

Pour ceux là, il faut obligatoirement qu’ils se définissent des ‘gentils’ langages, parfaits, idéaux et hégémoniques. Et puis des ‘méchants’ langages qui cumulent à eux seuls toutes les tares du monde. Entre les deux, point de salut.

C’est la seule façon qu’ils ont de se représenter les choses. Toute autre représentation un tant soit peu plus nuancée, pondérée et donc intrinsèquement plus complexe, dépasserait leurs capacités intellectuelles.

Et comme “ils osent tout et c’est même à ça qu’on les reconnait”, tu peux être sûr que ce sont eux en priorité qui vont se sentir obligés d’exprimer leur point de vue sur les espaces d’expression.

Altair31

Le 31/08/2016 à 05h25

Pour moi, l’onglet Gmail est le processus n°1 en consommation mémoire, devant éclipse.

150 Mo rien que pour lui en début de journée !

dylem29 Abonné

Le 30/08/2016 à 10h21

5% par onglet ! Wahou ! " /> 

Pas mal du tout. " />

Clapitti

Le 30/08/2016 à 10h36

Quid de la conso CPU?

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 30/08/2016 à 10h49

_Quentin_ a écrit :

J’ai rien compris, mais ça a l’air vachement chiadé " />

En gros, ils proposent que les développeurs fabriquent à partir de leur sources Javascript un fichier contenant du bytecode (avec l’extension .class) qu’ils compressent dans un fichier zip auquel ils donnent l’extension .jar

" />

 " />" />

 " />" />" />

Exagone313

Le 30/08/2016 à 10h49

En attente de la disparition de Javascript.

Liara T'soni

Le 30/08/2016 à 10h53

C’est bien, tu m’as fait rire. Maintenant réveil toi néo.

Nioniotte

Le 30/08/2016 à 10h55

Y a pas qu’avec JS que la consommation de mémoire vive doit être réduite… Chrome est un aspirateur à mémoire vive. Ceci dit en passant, Firefox fait pas mieux.

MoonRa

Le 30/08/2016 à 10h56

var me = “lol”;

Le JavaScript à un avenir radieux.

ndjpoye

Le 30/08/2016 à 10h58

On est pas dans la m…e " />

Exagone313

Le 30/08/2016 à 11h11

La plupart des pages web n’ont pas besoin réellement de Javascript. Je pense qu’il manque quelque chose pour pouvoir dynamiser sans Javascript, par exemple définir une zone comme étant un flux, et qui est mis à jour automatiquement, pour remplacer une partie d’ajax. J’aimerais vraiment voir le Javascript réduit à un bac à sable/plugin. Mais disons que je suis fanatique, avec NoScript.

Et le HTML/CSS pourraît être remplacé par des formes de contenu standardisées (mais qui définirait ces standards ?) - on pourrait plus facilement suivre localement notre thème GTK+/Qt/autre sans utiliser des extensions qui forcent plus ou moins un thème en CSS (faire du cas par cas est impossible). Aujourd’hui le web blanc/clair fait mal aux yeux, au sens propre.

En fait, il faudrait repenser un nouveau format de données, qui sépare design et contenu. Je vois tout de suite des gens m’entendre dire qu’il faut retourner à la préhistoire, mais évidemment que je ne veux pas que le web se referme. J’ai pas de prototype à montrer, et je vois un problème entre liberté et standardisation dans mon idée pour l’instant.

lossendae

Le 30/08/2016 à 11h24

C’est pas si mal que ça l’ecmascript 6

brazomyna

Le 30/08/2016 à 11h29

Exagone313 a écrit :

il faudrait repenser un nouveau format de données, qui sépare design et contenu.

Allez, soyons fous …

Je propose un couple de deux technos complémentaires, l’une pour le contenu sous forme structurée ; l’autre pour la représentation graphique.

Appelons les HTML pour le premier et CSS pour le second.

 

  

lossendae

Le 30/08/2016 à 11h30

Séparé design et contenu, comme du CSS et du HTML “grosso modo”.

Du web avec GTK+/Qt/autre truc bien lourd, c’est pas non plus l’idée du siècle.

Le web d’aujourd’hui leger et sans interface lourde me plait plus que la tres grande majorité des applications pleine de chrome souvent dégueulasse car faite par des gens qui n’ont aucune reflexion sur les interfaces pratique et jolies (c’est possible, il suffit de voir ce qui se fait sur OSX).

Liara T'soni

Le 30/08/2016 à 11h33

Il est vrai… NodeJS est un “client léger” et ça consommation de ram est 10x inférieur à chromium.

127.0.0.1

Le 30/08/2016 à 11h36

Oracle devrait porter plainte contre Google pour plagia de la JVM " />

brazomyna

Le 30/08/2016 à 11h40

Liara T’soni a écrit :

Il est vrai… NodeJS est un “client léger” et ça consommation de ram est 10x inférieur à chromium.

Il me semble avoir lu quelque part que même si Chrome et NodeJS partagent le même moteur JS, il y avait au final une assez grande différence de la façon dont est traitée le code JS, du fait d’une ‘configuration’ des paramètres du moteur (d’optimisation notamment) assez différente.

 J’ai pas vérifié par moi-même, mais ça me paraîtrait pas totalement déconnant: une appli NodeJS on s’en fout un peu qu’elle mette quelques millisecondes de plus à se lancer, ou qu’elle utilise quelques Mo de RAM temporairement utilisés pour compiler agressivement tout le code dès le départ. Par contre, l’important c’est qu’une fois l’appli lancée, il faut que ça dépote ensuite.

A l’inverse, le temps de chargement initial d’une page dans un browser, et sa conso en RAM sont des éléments importants (surtout quand on a 50 pages ouvertes en même temps)  ; sans doute bien plus important que quelques % de perfs en plus ou en moins dans l’exécution du code JS proprement dit.

 

Enfin, même si les deux parlent du JS, ils ont des traitements typiques plutôt distincts: en général, le code d’une page sert essentiellement à manipuler du DOM ; le code d’une appli JS est beaucoup plus orienté I/O et calculs.

 

sans sucre

Le 30/08/2016 à 11h42

mince je pourait pas utiliser sur mon thl 4000 " />

megabigbug

Le 31/08/2016 à 21h03

brazomyna a écrit :

C’est flagrant: l’ensemble de tes raisonnement se fondent sur les principes et les besoins relatifs à la création de ce que tu connais: les UI. 

Mon second exemple décrivait plus ou moins un layout 3 colonnes. Le genre de chose vraiment commun dans les sites Web et qui pourtant est resté longtemps difficile à faire en HTML/CSS sans bidouilles et même aujourd’hui avec les flexbox je trouve que c’est encore compliqué pour faire une chose aussi basique.

flamaros

Le 01/09/2016 à 11h41

lossendae a écrit :

Ca doit dependre de ta formation. 

Je trouve le couple HTML + CSS tres simple à utiliser. 

Et honnêtement, faire du style en JS, c’est à vomir… du moins pour le peu que j’ai essayé avec react + jsx.

Le QML n’est pas complètement du JS, c’est un language de description qui pour les bindings utilise du js.

Les bindings sont des fonctions exécutées automatiquement à chaque fois qu’une des propriétés que son code utilise change.

Si tu modifie la propriété width d’un élément A tous les autres éléments qui ont des propriétés qui dépendent de A.width se verront mis à jour correctement.

Les gros avantages sont de ne pas avoir à déclarer de callback ou autre, donc ça fait moins de code et les valeurs sont réévaluées dans le bon ordre en fonction des dépendances.

 

brazomyna a écrit :

Pour connaître les deux domaines il me paraît plus que probable que tu aies une bonne expérience en matière de création d’UI et une expérience quasi inexistante en matière de conception web.

C’est flagrant: l’ensemble de tes raisonnement se fondent sur les principes et les besoins relatifs à la création de ce que tu connais: les UI.
 Sauf que HTML/CSS c'est pas pour faire des UI pour des applications ; c'est fait pour faire ... des pages web. Or les pages web ont un contenu dont la nature est différente, un objectif différent, dont les terminaux, leur diversité, leurs interactions sont différents, etc...       
 En gros tu ressembles à un charpentier qui plante des clous toute la journée. Et ne jure que par les marteaux comme 'outil ultime'. Et tu nous expliques que les mécaniciens ont tort d'utiliser des tournevis pour leur tâches, parce qu'un marteau c'est quand même vachement mieux pour planter des clous.
Justement de plus en plus d’applications sont faites en web et une UI à aussi besoin de pouvoir afficher des données statique (documents). Le QML est bon à la fois pour créer de l’UI dynamique et des documents statiques.

Les interfaces web doivent aujourd’hui passer d’un écran PC à un smartphone, en html généralement c’est fait en faisant des pages web voir sites différents. En QML on peux le faire qu’une fois pour supporter l’ensemble des plateformes.

Franchement j’ai testé boostrap, ça à beau être pas mal, c’est super lourd, il faut un i7,… pour afficher une page avec un peu de contenu.

 

J’ai quand même l’impression que ce sont ces technologies web qui font que les navigateurs consomme autant de mémoire. Leur moteur est blindé de code pour gérer la compatibilité,…

brazomyna

Le 01/09/2016 à 11h53

flamaros a écrit :

j’ai testé boostrap, ça à beau être pas mal, c’est super lourd, il faut un i7,… pour afficher une page avec un peu de contenu.

Je crois qu’à ce stade le débat n’est plus nécessaire. " />

Il ne me reste qu’aà te souhaiter bon courage pour ta démarche d’évangélisation de Qml comme techno remplaçante de HTML/CSS

 

Altair31

Le 01/09/2016 à 14h39

damaki a écrit :

Et soit dit en passsant, pour Chrome, c’est pas évident de calculer son utilisation mémoire réelle à cause des process séparés et de la mémoire partagée.

Il suffit d’ouvrir le gestionnaire des tâches de chrome ;)

seblutfr a écrit :

C’est l’éternel problème : à chaque news, il y a des comparaisons de conso mémoire entre INpactiens, mais sans protocole précis. Tout dépend des pages ouvertes, de leur contenu, de la navigation effectuée, etc.

Pour être précis, il faudrait simplement un jour que quelqu’un fasse le même test avec les mêmes pages sur 2 navigateurs d’un même PC.

Pour ma part, le protocole c’est accéder à Gmail sur l’interface Inbox (pas leur truc tout pourri avec les onglets social, promotion, …).

Simple non?

Bon, il faut bien avouer que firefox ne fait pas mieux, ni pire.

Exagone313

Le 01/09/2016 à 19h33

Quand je parlais de design, je pensais à la forme du contenu, et non pas son style. Le style lui pourrait provenir du système. GTK+/autre n’est pas “lourd”, c’est simplement déjà présent dans le système. Je pense plus à quelque chose indépendant et compatible.

damaki Abonné

Le 02/09/2016 à 14h00

Je me vois difficilement faire confiance à un navigateur dire la vérité sur une caractéristique qui définit selon moi sa performance. L’OS ne ment pas.