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.
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.
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.
Le 22 novembre 2011 à 18:52
(15 358
lectures)
Il y a 38 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
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...)
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
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
dr_plans
Le mardi 22 novembre 2011 à 22:14:35
#5
Inscrit
le vendredi 17 septembre 04
-
716
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 n'est plus possible de commenter cette actualité
Vous devez être connecté ou vous inscrire en haut pour pouvoir participer aux commentaires.













