English feliratok

← Memory GC and Performance

Beágyazókód kérése
13 Languages

Showing Revision 4 created 05/25/2016 by Udacity Robot.

  1. Now that all of our code is
    running fast and awesome, let's
  2. talk a bit more about memory and how it
    affects the performance in our system.
  3. Many programming languages that are
    known for being close to the hardware,
  4. or rather, high performance,
    like C, C++,
  5. and Fortran, usually programmers
    to manage memory themselves.
  6. Effectively programmers
    are responsible for
  7. allocating a block of memory and then
    sometime in the future de-allocating
  8. it when they're actually done using it.
  9. Since you define when and how much
    memory to allocate in free, the entire
  10. quality of managing memory depends
    on your skills and effectiveness.
  11. That's a lot of responsibility.
  12. And the reality programmers aren't
    always the best at keeping track of
  13. all those bits and pieces of memory.
  14. I mean think about it,
    product development is a muddy and
  15. crazy process and often memory ends
    up not getting freed properly.
  16. These un-liberated blocks of memory, are
    called memory leaks and they just sit
  17. around hogging resources, that you
    could use better or somewhere else.
  18. To reduce this chaos, stress,
    and sometimes big money losses,
  19. caused by memory leaks,
    managed memory languages were created.
  20. The run times of these languages
    track memory allocations and
  21. release memory back to the system
    when it's no longer being needed by
  22. the application itself, all without
    any intervention from the programmer.
  23. This art, or rather science,
    of reclaiming memory in a managed memory
  24. environment is known as garbage
    collection, this concept was created by
  25. John McCarthy in 1959 to solve problems
    in the lisp programming language.
  26. The basic principles of garbage
    collection are as follows, number one,
  27. find data objects in a program that
    cannot be accessed in the future for
  28. example, any memory that is no
    longer referenced by the code.
  29. And number two, reclaim
    the resources used by those objects.
  30. Simple concept in theory, but
    it gets pretty complex once you've
  31. got 2 million lines of code and
    four gigs worth of allocations.
  32. Now think about it, garbage collection
    can be really gnarly, I mean,
  33. if you've got some 20,000 allocations
    in your program right now.
  34. Which ones aren't being needed anymore?
  35. Or better yet, when should you
    execute a garbage collection event
  36. to free up memory that isn't used?
  37. These are actually very
    difficult questions, and
  38. thankfully we've had about 50 years
    worth of innovation to improve them,
  39. which is why the garbage
    collector in Android's Runtime,
  40. is quite a bit more sophisticated
    than McCarthy's original proposal.
  41. It's been built to be as fast and
    non-intrusive as possible.
  42. Effectively the memory heaps in androids
    runtimes are segmented into spaces,
  43. based on the type of allocation and
  44. how best the system can organize
    allocations for future GC events.
  45. As a new object is allocated,
  46. these characteristics are taken into
    account to best fit what spaces should
  47. be placed into depending what version
    of the android runtime you're using.
  48. And here's the important part.
  49. Each space has a set size,
  50. as objects are allocated, we keep
    track of the combined sizes, and,
  51. as a space starts to grow, the system
    will need to execute a garbage
  52. collection event in an attempt to free
    up memory for future allocations.
  53. Now it's worth putting out that
    GC events will behave differently
  54. depending on what Android
    runtime you're using.
  55. For example, in Dalvik many GC events
    are stop the world events, meaning
  56. that any managed code that is running
    will stop until the operation completes.
  57. Which can get very problematic, when
    these GCs take longer than normal or
  58. there's a ton of them happening at once,
  59. since it's going to significantly
    eat into your frame time.
  60. >> And to be clear,
  61. the Android engineers have spent a lot
    of time making sure that these events
  62. are as fast as possible to reduce
    interruptions, that being said,
  63. they can still cause some application
    performance problems in your code.
  64. Firstly, understand that the more time
    your app is spending doing GCs in
  65. a given frame, the less time it's got
    for the rest of the logic needed to keep
  66. you under the 16 millisecond
    rendering barrier.
  67. So if you got a lot of GCs or some long
    ones that are occurring right after
  68. each other, it might put your frame
    processing time over the 16 millisecond
  69. rendering barrier, which will cause
    visible hitching or jank for your users.
  70. Secondly, understand that your code
    flow may be doing the kinds of work that
  71. force GCs to occur more often, or making
    them last longer than normal duration.
  72. For example, if you're allocating a
    hoard of objects in the inner most part
  73. of a loop that runs for a long time,
    then you're going to be polluting your
  74. memory heap with a lot of objects and
    you'll end up kicking off a lot of GCs
  75. quickly, due to this
    additional memory pressure.
  76. And even though we're in
    a managed memory environment,
  77. memory leaks can still happen.
  78. Although they're not as easy to
    create as the other languages.
  79. These leaks can pollute your heat
    with objects that won't get freed
  80. during a GC event, effectively reducing
    the amount of usable space you have and
  81. forcing more GC events to be kicked off,
    in a regular fashion as a result.
  82. So that's the deal, I mean,
  83. if you want to reduce the amount of GC
    events that happen in a given frame,
  84. then you need to focus on
    optimizing your apps memory usage.
  85. From a code perspective, it might be
    difficult to track down where problems
  86. like these are coming from, but
  87. thankfully, the Android SDK has a set
    of powerful tools at your disposal.
  88. Let's take a look.