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 de
  • 0:20 - 0:25
    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 cuando 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
    estar utilizando en otra parte.
  • 0:58 - 1:01
    Para reducir éste 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 éstos
    lenguajes rastrean las asignaciones y
  • 1:09 - 1:12
    liberan memoria al sistema cuando ya no
    hace falta a la
  • 1:12 - 1:16
    aplicación en sí misma. Sin ninguna
    intervención por parte del programador.
  • 1:16 - 1:20
    Éste 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 fue
  • 1:24 - 1:30
    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 bastante complejo cuando
  • 1:47 - 1:51
    tienes 2 millones de lineas 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
    Cuáles 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
    éstas 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
    vigilando los tamaños combinados, y
  • 2:44 - 2:47
    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 hasta
  • 3:04 - 3:05
    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:14
    Y, seamos claros,
  • 3:14 - 3:18
    los ingenieros de Android han invertido
    mucho tiempo en asegurarse de que éstos
  • 3:18 - 3:21
    eventos sean lo más rápidos posible para
    evitar interrupciones. Dicho esto,
  • 3:21 - 3:25
    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 en
  • 3:29 - 3:33
    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
    Asi que, si tienes un montón de GC, o
    algunos muy largos que ocurren uno
  • 3:38 - 3:42
    tras otro, eso podría ubicar tu tiempo de
    procesamiento de cuadros por sobre los 16
  • 3:42 - 3:42
    milisegundos
  • 3:42 - 3:45
    que es la barrera de renderización, lo
    que causaría ralentización o fallas a
  • 3:45 - 3:47
    tus usuarios.
  • 3:47 - 3:50
    En segundo lugar, entiende que el flujo
    del código pudiera estar haciendo cosas
  • 3:50 - 3:55
    que obligan a eventos GC más frecuentes
    o más largos de lo normal.
  • 3:55 - 3:59
    Por ejemplo, si estás asignando un montón
    de objetos en la parte interior
  • 3:59 - 4:02
    de un lazo que se ejecuta durante largo
    tiempo, contaminarás tu
  • 4:02 - 4:06
    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
    E 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
    Éstas 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