Return to Video

04-02 Memory,_GC,_and_Performance

  • 0:00 - 0:03
    Maintenant que tout notre code
    est optimisé et que tout marche bien
  • 0:03 - 0:08
    parlons un peu de mémoire et de son effet
    sur les performances dans notre système.
  • 0:08 - 0:12
    Les langages de programmation qui sont
    connus pour être proche du matériel,
  • 0:12 - 0:14
    ou plutôt, de haute performance,
    comme C, C ++,
  • 0:14 - 0:18
    et Fortran, exigent pour les programmeurs
    de gérer la mémoire eux-mêmes.
  • 0:18 - 0:20
    Les programmeurs sont responsables
  • 0:20 - 0:25
    de l'allocation d'un bloc de mémoire, puis
    ensuite de sa désallocation
  • 0:25 - 0:26
    quand ils ont fini de l'utiliser.
  • 0:26 - 0:31
    Comme vous définissez quand et combien
    de mémoire allouer,
  • 0:31 - 0:35
    la qualité de la gestion de mémoire dépend
    de vos compétences et de votre efficacité
  • 0:35 - 0:36
    Une grande responsabilité.
  • 0:36 - 0:40
    En réalité, les programmeurs
    ne sont pas toujours les meilleurs
  • 0:40 - 0:42
    pour garder la trace
    de ces fragments de mémoire.
  • 0:42 - 0:46
    Pensez-y, le développement de produits
    est un processus laborieux et précis.
  • 0:46 - 0:49
    Et la mémoire finit souvent
    par ne pas être libérée proprement.
  • 0:49 - 0:53
    Ces blocs non libérés de mémoire, ce sont
    les fuites de mémoire et ils restent là
  • 0:53 - 0:58
    monopolisant les ressources que
    vous pourriez utiliser mieux ou ailleurs.
  • 0:58 - 1:01
    Pour réduire ce chaos, ce stress,
    voire de grosses pertes d'argent
  • 1:01 - 1:05
    dûes aux fuites de mémoire, on a créé
    des langages avec gestion de mémoire.
  • 1:05 - 1:08
    Ces langages permettent de
    suivre les allocations de mémoire
  • 1:08 - 1:12
    et libèrent la mémoire pour le système
    quand elle n'est plus nécessaire
  • 1:12 - 1:16
    pour l'application elle-même, le tout
    sans aucune intervention du programmeur.
  • 1:16 - 1:20
    Cet art, voire science, de récupération
    de mémoire dans un environnement
  • 1:20 - 1:24
    de gestion de mémoire est appelé :
    garbage collection, concept créé par
  • 1:24 - 1:30
    John McCarthy en 1959 pour résoudre
    les problèmes dans le langage Lisp.
  • 1:30 - 1:33
    Les grands principes du garbage collection
    sont les suivants : numéro un,
  • 1:33 - 1:37
    retrouver les données d'objets qui
    ne seront plus accessibles à l'avenir
  • 1:37 - 1:40
    par exemple, toute mémoire
    n'étant plus référencée par le code.
  • 1:40 - 1:44
    Numéro deux, récupérer
    les ressources utilisées par ces objets.
  • 1:44 - 1:47
    Concept simple en théorie qui devient
    assez complexe lorsque vous avez
  • 1:47 - 1:51
    2 millions de lignes de code et
    quatre gigas pour les allocations.
  • 1:51 - 1:53
    Pensez-y, le garbage collection
    peut être assez tordu, ainsi,
  • 1:53 - 1:57
    si vous avez quelque 20 000 allocations
    dans votre programme en ce moment,
  • 1:57 - 1:58
    lesquelles sont inutiles ?
  • 1:58 - 2:02
    Mieux : quand faut-il exécuter
    un événement de garbage collection
  • 2:02 - 2:04
    pour libérer de la mémoire
    qui ne sert plus ?
  • 2:04 - 2:06
    Ce sont des questions
    très difficiles en fait,
  • 2:06 - 2:10
    heureusement nous avons eu environ 50 ans
    d'innovation pour les améliorer,
  • 2:10 - 2:12
    c'est pourquoi le garbage collector
    dans Android,
  • 2:12 - 2:15
    est un peu plus sophistiqué
    que la proposition originale de McCarthy.
  • 2:15 - 2:19
    Il a été conçu pour être rapide
    et le moins intrusif possible.
  • 2:19 - 2:23
    Sur android la mémoire s'empile, les temps
    d’exécution se partagent en espaces
  • 2:23 - 2:26
    sur la base du type d'allocation
    et de la meilleure façon pour le système
  • 2:26 - 2:28
    de gérer les allocations
    pour les futurs GC.
  • 2:28 - 2:30
    Quand un nouvel objet est alloué,
  • 2:30 - 2:34
    ces caractéristiques sont considérées
    pour sélectionner les meilleurs espaces
  • 2:34 - 2:37
    selon la version d'Android runtime
    que vous utilisez.
  • 2:37 - 2:39
    Et voici la partie importante.
  • 2:39 - 2:41
    Chaque espace a une taille définie,
  • 2:41 - 2:44
    À mesure que les objets sont alloués,
    nous suivons le total des tailles
  • 2:44 - 2:47
    et quand un espace commencera à grandir,
    le système devra faire un événement
  • 2:47 - 2:52
    de garbage collection pour libérer de la
    mémoire pour les prochaines allocations.
  • 2:52 - 2:55
    Maintenant, il faut préciser
    que les événements GC diffèreront
  • 2:55 - 2:57
    selon le runtime Android
    que vous utilisez.
  • 2:57 - 3:01
    Par exemple, avec Dalvik les événements GC
    sont du type : « stop the world »,
  • 3:01 - 3:05
    ainsi tout code géré qui s'exécute
    s'arrête jusqu'à la fin de l'opération.
  • 3:05 - 3:09
    ce qui peut devenir problématique, lorsque
    ces GC durent plus longtemps
  • 3:09 - 3:11
    ou quand il y en a un peu trop à la fois,
  • 3:11 - 3:14
    car cela va considérablement
    influencer votre fréquence d'images
  • 3:14 - 3:15
    - Et soyons clairs,
  • 3:15 - 3:18
    Les ingénieurs Android ont beaucoup
    travaillé pour que ces événements
  • 3:18 - 3:22
    soient aussi courts que possible pour
    réduire les interruptions, cela étant dit,
  • 3:22 - 3:25
    ils peuvent encore causer des problèmes
    de performance d'appli dans votre code.
  • 3:25 - 3:29
    Tout d'abord, comprenez que plus
    votre appli. prend du temps à faire du GC
  • 3:29 - 3:32
    sur une frame donnée, moins elle en a pour
    le reste du circuit logique
  • 3:32 - 3:36
    qu'il faut pour rester sous la barrière
    des 16 millisecondes de rendu.
  • 3:36 - 3:39
    Donc si vous avez pleins ou de longs GC
    se produisant d'affilée,
  • 3:39 - 3:42
    cela pourrait faire passer votre de temps
    de traitement de frame au-dessus de
  • 3:42 - 3:47
    ces 16 millisecondes de rendu, causant
    des saccades pour vos utilisateurs.
  • 3:47 - 3:50
    Deuxièmement, sachez que votre flux
    de code peut faire le genre de choses
  • 3:50 - 3:55
    qui entraîne plus de GC, ou les faire
    durer plus longtemps que la durée normale.
  • 3:55 - 3:59
    Par exemple, si vous allouez beaucoup
    d'objets dans la partie la plus interne
  • 3:59 - 4:02
    d'une boucle qui dure longtemps,
    alors vous allez polluer
  • 4:02 - 4:06
    votre tas de mémoire avec trop d'objets et
    vous allez avoir un grand nombre de GC
  • 4:06 - 4:09
    rapidement, du fait de cette pression
    supplémentaire sur la mémoire
  • 4:09 - 4:12
    Même dans un environnement
    de mémoire contrôlée,
  • 4:12 - 4:13
    des fuites de mémoire
    peuvent se produire.
  • 4:13 - 4:17
    Bien qu'elles ne soient pas aussi faciles
    à créer qu'avec les autres langages.
  • 4:17 - 4:21
    Ces fuites peuvent polluer votre tas
    avec des objets qui ne seront pas libérés
  • 4:21 - 4:24
    avec un événement de GC, réduisant
    la quantité d'espace utilisable
  • 4:24 - 4:27
    et entraînant plusieurs événements de GC,
    de façon régulière par la suite.
  • 4:27 - 4:29
    C'est donc ça le truc,
  • 4:29 - 4:32
    Si vous voulez réduire la quantité de GC
    qui se produit dans une frame donnée,
  • 4:32 - 4:36
    alors vous devez optimiser l'utilisation
    de la mémoire de vos applications.
  • 4:36 - 4:39
    Sur le plan du code, traquer l'origine
    de ce genre de problèmes
  • 4:39 - 4:41
    peut être compliqué.
  • 4:41 - 4:45
    Heureusement, le SDK Android dispose d'un
    ensemble d'outils puissants pour vous.
  • 4:45 - 4:46
    Jetons-y un coup d’œil.
Title:
04-02 Memory,_GC,_and_Performance
Description:

04-02 Memory,_GC,_and_Performance

more » « less
Video Language:
English
Team:
Udacity
Project:
ud825 - Android Performance
Duration:
04:47

French subtitles

Revisions Compare revisions