Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Practical resource management for mobile device...

Avatar for Max Klyga Max Klyga
February 22, 2014

Practical resource management for mobile devices: Pooling is magic

A collection of advices and optimisations for efficient use of resources on mobile devices

Avatar for Max Klyga

Max Klyga

February 22, 2014
Tweet

More Decks by Max Klyga

Other Decks in Programming

Transcript

  1. P O O L I N G I S M

    A G I C P R A C T I C A L R E S O U R C E M A N A G E M E N T F O R M O B I L E D E V I C E S
  2. W H AT D O W E K N O

    W A B O U T M O B I L E
  3. W H AT D O W E K N O

    W A B O U T M O B I L E • Battery is limited
  4. W H AT D O W E K N O

    W A B O U T M O B I L E • Battery is limited • Processing power is limited
  5. W H AT D O W E K N O

    W A B O U T M O B I L E • Battery is limited • Processing power is limited • Storage is limited
  6. W H AT D O W E K N O

    W A B O U T M O B I L E • Battery is limited • Processing power is limited • Storage is limited • RAM is limited
  7. W H AT D O W E K N O

    W A B O U T M O B I L E • Battery is limited • Processing power is limited • Storage is limited • RAM is limited • Ubiquitous
  8. W H AT D O W E K N O

    W A B O U T G A M E S
  9. W H AT D O W E K N O

    W A B O U T G A M E S • Consume all of the CPU
  10. W H AT D O W E K N O

    W A B O U T G A M E S • Consume all of the CPU • Consume all of the GPU
  11. W H AT D O W E K N O

    W A B O U T G A M E S • Consume all of the CPU • Consume all of the GPU • Can consume a lot of storage space
  12. W H AT D O W E K N O

    W A B O U T G A M E S • Consume all of the CPU • Consume all of the GPU • Can consume a lot of storage space • Consume all of RAM
  13. W H AT D O W E K N O

    W A B O U T G A M E S • Consume all of the CPU • Consume all of the GPU • Can consume a lot of storage space • Consume all of RAM • Thats what people do on mobile
  14. R E D U C E B AT T E

    RY C O N S U M P T I O N • Reduce your network activity • Every time cell radio is activated for 20-30 seconds • Batch requests • Prefetch as much data as possible • Maximize bandwidth usage • Reduce storage activity • Don’t keep threads busy for no reason
  15. R E D U C E A P P L

    I C AT I O N S I Z E • Different assets for different device categories • Use a smaller runtime if available • Use texture atlases • Enable batch drawing • Less memory • Use compressed textures where possible • Use WebP for uncompressed images
  16. G A M E S A R E D I

    F F E R E N T
  17. G A M E S A R E D I

    F F E R E N T • A lot is known in advance: • Usage patterns are known • Data dependencies are known • Asset restrictions are known
  18. U S E Y O U R K N O

    W L E D G E
  19. U S E Y O U R K N O

    W L E D G E • Set restrictions for designers and artists • Custom build process: • Use available tools • Write your own
  20. M E M O RY A L L O C

    AT I O N PAT T E R S • Application scope (allocated at app start, freed on shutdown) • Level scope (allocated at level start, freed on level end) • Frame scope (allocated for one frame, sometimes for two) • Temporary allocations
  21. M E M O RY A L L O C

    AT I O N PAT T E R N S • Grab all required memory once on app start - this is all you will have • Divide it between several heaps for different subsystems (avoids fragmentation, decoupling) • Use stack allocations where possible (alloca, structs, static arrays)
  22. G O T TA G O FA S T •

    Linear allocator: • Just increase the pointer and adjust for alignment • As fast as it can get • Free all memory at once (reset pointer)
  23. L I N E A R A L L O

    C AT O R • Can only free in reverse order (better free all at once at scope exit) • How do we deal with temporary allocations? • Separate heap for temporaries? • Nope! Double-ended linear allocator • What about cleanup? • Scope stack (http://dice.se/publications/scope-stack- allocation/)
  24. B U T WA I T, W H AT A

    B O U T • Objects with undefined lifetime: • Use object pools • Objects with variable size: • Custom allocator (several free-lists for different sizes)
  25. O B J E C T P O O L

    S • Preallocate certain number of objects of same type • Use objects from pool whenever one needs an object of that type • Return objects to pool when done (resource released, reference count is zero) • Can process all the pool in one go • Better cache efficiency • Set restrictions on object count
  26. O B J E C T P O O L

    S • Particle systems • Components • Game entities • Sounds • etc.
  27. R E S O U R C E L I

    F E T I M E • Use registers for resources of same type (fonts, textures, etc.) • Use reference counters only as last resort: • Thrash CPU cache • Unnecessary work • Unbounded pauses on deallocation cascades
  28. R E S O U R C E L I

    F E T I M E • Don’t leave some resource hanging if it will be reused in some other level • Usually its ok to unload and load stuff again to avoid heap fragmentation
  29. R E D U C E M E M O

    RY U S A G E • ‘Prototype’ pattern: • Extract some part to be shared by all objects • Usually used as a template for creating stuff • Best allocation is no allocation at all
  30. ‘ P R O T O T Y P E

    ’ PAT T E R N • Animations • Game entities (Similar to prefabs in Unity) • Anything that could share an immutable part between instances
  31. R E D U C E M E M O

    RY U S A G E • Unity: • Use value types (structs, primitive types) • Avoid boxing/unboxing • Don’t use default GUI • Reuse buffers and objects where possible
  32. • Always base your decisions on data • USE PROFILER

    • Don’t use this rules as a dogma, think for yourself
  33. S TA R T P R E A L L

    O C AT I N G A N D S T O P W O R RY I N G
  34. Q U E S T I O N S ?

    M A X K LY G A E M A I L : M A X . K LY G A @ G M A I L . C O M T W I T T E R : @ N E K U 4 2