Practical resource management for mobile devices: Pooling is magic

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

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
15. 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
16. 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
17. G A M E S A R E D I F F E R E N T
18. 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
19. U S E Y O U R K N O W L E D G E
20. 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
21. 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
22. 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)
23. 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)
24. 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/)
25. 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)
26. 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
27. O B J E C T P O O L S • Particle systems • Components • Game entities • Sounds • etc.
28. 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
29. 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
30. 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
31. ‘ 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
32. 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
33. • Always base your decisions on data • USE PROFILER • Don’t use this rules as a dogma, think for yourself
34. 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
35. 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