In a pattern like this: - allocate 100 bytes - allocate 200 bytes - allocate 50 bytes - allocate 100000000 bytes - allocate 100 bytes - allocate 200 bytes - allocate 50 bytes The DynamicBuffer class switches to making 100MB allocations even if that allocation was a one-off. A small future allocation would then tie up 100MB in memory for future allocations. Another 100MB is also left tied up in the free list. With this change, if an allocation is made that's less than a quarter of the DynamicBuffer's current allocation size, it's taken as a sign that the previous large allocation was a one-off and the size is moved back to the DynamicBuffer's original initial size. Bug: b/187757166 Bug: chromium:1224952 Change-Id: Icb69bfa3196daa1ee8e6c38ef9513730f9afacfa Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2991915Reviewed-by:Jamie Madill <jmadill@chromium.org>
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| android_system_settings | Loading commit data... | |
| common | Loading commit data... | |
| compiler | Loading commit data... | |
| feature_support_util | Loading commit data... | |
| gpu_info_util | Loading commit data... | |
| image_util | Loading commit data... | |
| libANGLE | Loading commit data... | |
| libEGL | Loading commit data... | |
| libGL | Loading commit data... | |
| libGLESv1_CM | Loading commit data... | |
| libGLESv2 | Loading commit data... | |
| libOpenCL | Loading commit data... | |
| tests | Loading commit data... | |
| third_party | Loading commit data... | |
| commit_id.py | Loading commit data... | |
| compiler.gni | Loading commit data... | |
| copy_compiler_dll.bat | Loading commit data... | |
| libGLESv2.gni | Loading commit data... |