On 8/17/22 18:31, Steven Schveighoffer wrote:
> 1. I highly recommend trying out the ring buffer solution to see if it
> helps. The disadvantage here is that you need to tie up at least a page
> of memory.
I started to think holding on to multiple pages of memory should not
matter anyway. If really needed, an array of Appenders could be used;
when really really needed, they may come from a free list.
Aside: I looked at Appender's implementation and saw that extending is
one of its concerns as well.
> 2. All my tests using the ring buffer showed little to no performance
> improvement over just copying back to the front of the buffer. So
> consider just copying the data back to the front of an already allocated
> block.
That makes sense as well. One worry would be types with copy
constructors. (I am not sure whether D is still a language where structs
can freely be moved around.)
> IIRC, your data does not need to be sequential in *physical memory*,
> which means you can use a ring buffer that is segmented instead of
> virtually mapped, and that can be of any size.
I thought about that as well. But I would like the sizes of blocks
(Appenders?) be equal in size so that opIndex still can provide O(1)
guarantee. (Compute the block + an offset.)
>
> -Steve
Ali
