Overallocate geomBuffer. #941
Conversation
manthey
force-pushed
the
overallocate-geometry-buffers
branch
from
46a0f23 to
bd5abc6
Compare
| * Add an extra factor of allocateLarger, but if a power-of-two is between | ||
| * the specified size and the larger permitted size, perfer the power-of- | ||
| * two. */ | ||
| var allocate = len; |
There was a problem hiding this comment.
why do we care for power of two?
There was a problem hiding this comment.
We might not. In general, many memory allocation schemes have different pools that change when a power-of-two boundary is crossed. I don't actually know if Firefox or Chrome do (they used to, but they may no longer do so). By choosing a power-of-two when convenient, it is possible that we will use the memory pool for smaller objects in preference to the larger. The optimization is a guess -- if the buffer gets reallocated bigger, then the smaller size is wasted. If it doesn't get bigger, then we might gain an efficiency.
I can take it out if you'd prefer.
There was a problem hiding this comment.
I can take it out if you'd prefer.
I have a slight preference to take it out since this behavior is not documents in the 'user documentation' plus it complicates things further without clear benefit.
When reusing an existing buffer for webGL, permit it to be larger than strictly necessary. If reallocating an existing buffer, allocate some extra space. For dynamic data sets, this avoids reallocating buffers on every geometry update, substantially reducing garbage collection. In one examples with ~35,000 lines containing a total of ~1,000,000 vertices where the number of vertices changes periodically, this reduced geometry update time by ~200 ms.
manthey
force-pushed
the
overallocate-geometry-buffers
branch
from
bd5abc6 to
0a9172d
Compare
When reusing an existing buffer for webGL, permit it to be larger than strictly necessary. If reallocating an existing buffer, allocate some extra space. For dynamic data sets, this avoids reallocating buffers on every geometry update, substantially reducing garbage collection.
In one examples with ~35,000 lines containing a total of ~1,000,000 vertices where the number of vertices changes periodically, this reduced geometry update time by ~200 ms.