On 8/16/22 2:11 PM, Ali Çehreli wrote:
Related to my DConf 2022 lightning talk, I am noticing that D runtime's
in-place array extension optimization is available only for array data
that are at certain memory alignments.
No, it's based on 2 factors:
1. Is it a page-size-or-greater block?
2. Is there a free page after it?
The smaller blocks are stored in page-sized pools and *cannot* be
combined together. e.g. you can't have 2 16-byte blocks joined to form a
32 byte block.
The reason why your `bad` version fails is because when it must
reallocate, it still is only allocating 1 element.
Now a page is 4096 bytes typically. So why does the 2048 amount work?
Because in order to store a 2048 byte array, you need 2048 bytes AND the
metadata (e.g. typeinfo for destruction and append capacity). This
requires a full page.
Note that once you reach page size, the optimization can happen, *even
if you are only appending to an end slice*. Here's something to try:
when the capacity is less than the "magic" number of elements, `reserve`
that number of elements. Then the "drop one element each loop" should
use the optimization.
-Steve
