Return to Video

04-02 Memory,_GC,_and_Performance

  • 0:00 - 0:03
    Ahora que todo nuestro código
    se ejecuta rápido y genial, hablemos
  • 0:03 - 0:08
    un poco más acerca de la memoria y cómo
    afecta el rendimiento en nuestro sistema.
  • 0:08 - 0:12
    Muchos lenguajes de programación
    conocidos por ser cercanos al hardware,
  • 0:12 - 0:14
    o más bien, de alto desempeño
    como C, C++
  • 0:14 - 0:18
    y Fortran, los programadores suelen tener
    que administrar la memoria ellos mismos.
  • 0:18 - 0:20
    Los programadores son los responsables
  • 0:20 - 0:25
    de asignar un bloque de memoria
    y, posteriormente, desasignarlo
  • 0:25 - 0:26
    cuando han terminado de utilizarlo,
  • 0:26 - 0:31
    dado que uno mismo define cuándo y
    cuánta memoria asignar, toda la
  • 0:31 - 0:35
    calidad de la administración de memoria
    depende de tus habilidades y efectividad.
  • 0:35 - 0:36
    Es mucha responsabilidad.
  • 0:36 - 0:40
    Y la realidad es que los programadores
    no siempre son los mejores en controlar
  • 0:40 - 0:42
    todos esos trocitos de memoria.
  • 0:42 - 0:45
    Piénsalo, el desarrollo
    de productos es laborioso y
  • 0:45 - 0:49
    agitado, y muchas veces la memoria
    acaba no siendo liberada correctamente.
  • 0:49 - 0:53
    Esos bloques de memoria sin liberar
    son llamados fugas de memoria, y andan
  • 0:53 - 0:58
    por ahí acaparando recursos
    que podrías utilizar en otra parte.
  • 0:58 - 1:01
    Para reducir este caos, estrés, e incluso
    grandes pérdidas monetarias,
  • 1:01 - 1:05
    causadas por fugas de memoria, se crearon
    los lenguajes de memoria administrada.
  • 1:05 - 1:09
    Los tiempos de ejecución de estos
    lenguajes rastrean las asignaciones y
  • 1:09 - 1:12
    liberan memoria al sistema
    cuando ya no le hace falta
  • 1:12 - 1:16
    a la aplicación en sí misma. Sin ninguna
    intervención por parte del programador.
  • 1:16 - 1:20
    Este arte, o más bien ciencia,
    de recuperar memoria en un ambiente
  • 1:20 - 1:24
    de memoria administrada, se conoce como
    "recolección de basura", el concepto
  • 1:24 - 1:30
    fue creado en 1959 por John McCarthy para
    resolver problemas en el lenguaje LISP.
  • 1:30 - 1:33
    Los principios básicos de recolección
    de basura son: número uno,
  • 1:33 - 1:37
    encontrar objetos de datos en un programa
    al que no se puede acceder en el futuro,
  • 1:37 - 1:40
    por ejemplo, cualquier memoria que ya
    no esté referida por el código.
  • 1:40 - 1:44
    Y número dos, recuperar los recursos
    utilizados por dichos objetos.
  • 1:44 - 1:47
    El concepto es simple en teoría,
    pero se vuelve bastante complejo
  • 1:47 - 1:51
    cuando tienes 2 millones de líneas
    de código y cuatro gigas de asignaciones.
  • 1:51 - 1:53
    Piénsalo, la recolección de basura
    puede ser realmente irritante,
  • 1:53 - 1:57
    si tienes unas 20.000 asignaciones
    en tu programa ahora mismo,
  • 1:57 - 1:58
    ¿cuales ya no se necesitan?
  • 1:58 - 2:01
    O mejor, ¿cuándo debes ejecutar un evento
    de recolección de basura
  • 2:01 - 2:04
    para liberar memoria sin utilizar?
  • 2:04 - 2:06
    Éstas preguntas son realmente difíciles y
  • 2:06 - 2:10
    afortunadamente, hemos tenido unos
    50 años de innovación para mejorarlas.
  • 2:10 - 2:12
    Por eso el recolector de basura
    en el tiempo de ejecución de Android
  • 2:12 - 2:15
    es bastante más sofisticado que
    la propuesta original de McCarthy.
  • 2:15 - 2:19
    Ha sido creado para ser tan rápido y
    no invasivo como sea posible.
  • 2:19 - 2:22
    En efecto, las pilas de memoria
    en los tiempos de ejecución de Android
  • 2:22 - 2:23
    están segmentadas en espacios
  • 2:23 - 2:24
    basado en el tipo de asignación y
  • 2:24 - 2:28
    en cómo el sistema puede organizar mejor
    las asignaciones para futuros eventos GC.
  • 2:28 - 2:30
    Cuando se asigna un nuevo objeto,
  • 2:30 - 2:33
    estas características son tomadas en
    cuenta para ajustarse a los espacios
  • 2:33 - 2:37
    más adecuados, dependiendo de la versión
    del tiempo de ejecución Android que uses.
  • 2:37 - 2:39
    Y aquí viene lo importante:
  • 2:39 - 2:41
    cada espacio tiene un tamaño específico.
  • 2:41 - 2:44
    A medida que se asignan objetos, se van
    se van vigilando los tamaños combinados
  • 2:44 - 2:47
    y cuando el tamaño empieza a crecer, el
    sistema tendrá que ejecutar un evento
  • 2:47 - 2:52
    de recolección de basura, intentando
    liberar memoria para futuras asignaciones.
  • 2:52 - 2:54
    Vale destacar que los eventos de GC
    se comportan de forma diferente
  • 2:54 - 2:57
    dependiendo de cuál tiempo
    de ejecución de Android se utilice.
  • 2:57 - 3:01
    Por ejemplo, en Dalvik, muchos eventos
    de GC detienen los eventos mundiales,
  • 3:01 - 3:04
    así, cualquier código administrado
    que se esté ejecutando se detiene
  • 3:04 - 3:05
    hasta completar la operación.
  • 3:05 - 3:09
    Lo que genera problemas cuando los GC
    tardan más de lo normal, o cuando
  • 3:09 - 3:11
    ocurren muchos al mismo tiempo.
  • 3:11 - 3:14
    dado que van a consumir parte
    significativa de tu tiempo.
  • 3:14 - 3:15
    y, seamos claros,
  • 3:15 - 3:18
    los ingenieros de Android han invertido
    mucho tiempo en asegurarse de que
  • 3:18 - 3:21
    estos eventos sean lo más rápidos posible
    para evitar interrupciones.
  • 3:21 - 3:25
    Dicho esto, pueden causar problemas en el
    desempeño de aplicaciones en tu código.
  • 3:25 - 3:29
    En primer lugar, entiende que, mientras
    más tiempo pase tu app haciendo GC
  • 3:29 - 3:33
    en cierto marco, menos tiempo tendrá para
    el resto de la lógica que necesita para
  • 3:33 - 3:35
    mantenerte bajo la barrera de
    renderización de 16 milisegundos.
  • 3:35 - 3:38
    Así que, si tienes muchos GC, o
    algunos muy largos que ocurren uno
  • 3:38 - 3:41
    tras otro, eso podría ubicar tu tiempo de
    procesamiento de cuadros por sobre
  • 3:41 - 3:42
    los 16 milisegundos
  • 3:42 - 3:45
    que es la barrera de renderización, lo
    que causaría ralentización o fallas
  • 3:45 - 3:47
    a tus usuarios.
  • 3:47 - 3:50
    En segundo lugar, entiende que el flujo
    del código puede estar haciendo cosas
  • 3:50 - 3:55
    que obliguen a eventos GC más frecuentes
    o más largos de lo normal.
  • 3:55 - 3:59
    Por ejemplo, si estás asignando muchos
    objetos en la parte interior
  • 3:59 - 4:02
    de un lazo que se ejecuta durante largo
    tiempo, contaminarás
  • 4:02 - 4:06
    tu pila de memoria con muchos objetos
    y acabarás generando muchos GC
  • 4:06 - 4:09
    rápidamente, debido a ésta
    presión adicional sobre la memoria.
  • 4:09 - 4:12
    Incluso considerando que estamos en
    un ambiente de memoria administrada,
  • 4:12 - 4:13
    pueden ocurrir fugas de memoria.
  • 4:13 - 4:17
    Aunque no es tan fácil crearlas
    como en otros lenguajes.
  • 4:17 - 4:20
    Estas fugas pueden contaminar tu pila
    con objetos que no se liberan
  • 4:20 - 4:24
    durante un evento GC, reduciendo
    efectivamente el espacio utilizable y
  • 4:24 - 4:27
    obligando a que ocurran
    más eventos GC con regularidad.
  • 4:27 - 4:29
    Así que eso es,
  • 4:29 - 4:33
    si quieres reducir la cantidad de GC
    que ocurren en un cierto plazo,
  • 4:33 - 4:36
    debes enfocarte en optimizar
    el uso de memoria de las apps.
  • 4:36 - 4:39
    Desde una perspectiva de código, puede
    ser difícil detectar de dónde
  • 4:39 - 4:41
    salen éstos problemas, pero
  • 4:41 - 4:44
    afortunadamente, el Android SDK pone
    un juego de poderosas herramientas
  • 4:44 - 4:45
    a tu disposición.
  • 4:45 - 4:46
    Veamos.
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

Spanish subtitles

Revisions Compare revisions