S'identifier / Créer un compte
  • Actualités
  • Dossiers
  • Tests
  • Commentaires
  • INpactiens
Publicité

Google améliore sa machine virtuelle JavaScript V8

Non, ce n'est jamais terminé

Dans un billet sur le blog de Chromium hier, des ingénieurs de Google ont annoncé une avancée significative en termes de performances dans un domaine bien précis : le ramasse-miettes.

chrome

Le ramasse-miettes, ou garbage collector en anglais, est un sous-système entièrement consacré au recyclage de la mémoire. Lorsqu’une application s’exécute, des zones de la mémoire vive lui sont allouées. Lorsque ces zones deviennent inutilisées, elles doivent être réclamées. Le ramasse-miettes a pour mission, dans les grandes lignes, de vérifier dans la mémoire que des zones libres n’y trainent pas, afin de les collecter et de les remettre dans le « pool » de mémoire disponible.

Le problème du ramasse-miettes est que son fonctionnement même influe sur les performances de l’application. Dans le cas du web, la poussée du WebGL et du HTML5 provoque de nouveaux besoins en termes de rapidité, ce que Google nomme « performances interactives ». Traduction : pas le temps d’attendre.

Dans le cas de machine virtuelle JavaScript V8 de Chrome, c’est la mise en place d’un ramasse-miettes incrémentiel qui doit changer la donne. Par incrémentiel, il faut comprendre qu’il collecte progressivement les zones libérées de mémoire, en alternant les cycles de ce travail avec ceux de l’application, pour ne pas provoquer de coupures dans cette dernière.

Ainsi, Google s’est basé sur les tests de performance les plus intensifs de la V8 Benchmark Suite et a obtenu un temps d’affichage d’une image de 50 ms en incluant les pauses engendrées par le ramasse-miettes, au lieu de 272 ms précédemment.

Les développeurs qui voudraient tester les nouvelles performances devront d’abord récupérer la dernière version dev de Chrome depuis cette page.
Source : Google
Vincent Hermann

Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.

Publiée le 22/11/2011 à 18:52

Soutenez l'indépendance de Next INpact en devenant Premium

  • Tout le contenu de Next INpact sans pub
  • Et bien plus encore...

Il y a 38 commentaires

Avatar de frogi55 INpactien
frogi55 Le mardi 22 novembre 2011 à 19:10:51
Inscrit le mercredi 19 mai 10 - 29 commentaires
Les développeurs qui voudraient tester les nouvelles performances devront d’abord récupérer la dernière version dev de Chrome depuis cette page.

La page en question vu qu'il manque le lien : dev.chromium.org/getting-involved/dev-channel

Edité par frogi55 le mardi 22 novembre 2011 à 19:11
Avatar de rastadidi INpactien
rastadidi Le mardi 22 novembre 2011 à 20:56:40
Inscrit le vendredi 27 mars 09 - 44 commentaires
et sinon on la voit arriver quand dans android cette fameuse machine virtuelle ? nan parce que les perfs du navigateur integrer sont au ras des paquerettes, surtout en ce qui concerne la manipulation du dom (je crois pas qu'il y ai de comparaison possible entre ff mobile/opera mobile et chrome mobile...)
Avatar de Sebdraluorg INpactien
Sebdraluorg Le mardi 22 novembre 2011 à 21:51:04
Inscrit le jeudi 12 mai 05 - 1533 commentaires
Ainsi, Google s’est basé sur les tests de performance les plus intensifs de la V8 Benchmark Suite et a obtenu un temps d’affichage d’une image de 50 ms en incluant les pauses engendrées par le ramasse-miettes, au lieu de 272 ms précédemment.

Euh faut-il comprendre par là qu'avant il passait plus de 3/4 du temps à gerer la memoire pour afficher une image ?


Edité par Sebdraluorg le mardi 22 novembre 2011 à 21:51
Avatar de vinpowful INpactien
vinpowful Le mardi 22 novembre 2011 à 22:14:18
Inscrit le jeudi 20 octobre 11 - 5 commentaires
Ainsi, Google s’est basé sur les tests de performance les plus intensifs de la V8 Benchmark Suite et a obtenu un temps d’affichage d’une image de 50 ms en incluant les pauses engendrées par le ramasse-miettes, au lieu de 272 ms précédemment.

Euh faut-il comprendre par là qu'avant il passait plus de 3/4 du temps à gerer la memoire pour afficher une image ?


50 ms c'est énorme s'il ne s'agit que d'afficher une image (à moins qu'elle soit très haute définition, à ce rythme là on a du 20 images / s).

Je pense qu'il s'agit plutôt de générer une image, et selon les techniques cela peut solliciter la création/destruction de nombreux objets en mémoire, et à ce moment là cela devient pertinent pour tester les performances d'un garbage collector.

Il me semble d'ailleurs que dans le domaine du jeu vidéo, Java est boudé principalement à cause de son garbage collector qui ne peut pas être contrôlé par le développeur, et qui provoque des chutes de framerate lorsqu'il se met en route
Avatar de dr_plans INpactien
dr_plans Le mardi 22 novembre 2011 à 22:14:35
Inscrit le vendredi 17 septembre 04 - 765 commentaires
Ainsi, Google s’est basé sur les tests de performance les plus intensifs de la V8 Benchmark Suite et a obtenu un temps d’affichage d’une image de 50 ms en incluant les pauses engendrées par le ramasse-miettes, au lieu de 272 ms précédemment.

ça me frappe aussi...
Soit leur browser était à la ramasse avec un temps de 272ms soit c'est un gain impressionnant !

Il y a 38 commentaires

;