The main point of the allocator, as for any region allocator, is to make many small, short-lived allocations fast by only performing a single more expensive allocation instead, so the comment about being pointless seems a bit odd?

Two issues:

• Duplicating the RegionListAllocator implementation here instead of modifying the one in vibe-container is rather messy, I'd rather add a new method to the original, or maybe a Flag!"freeMemory" free_memory = Yes.freeMemory default parameter for deallocateAll().
• This may only be done for version (VibeManualMemoryManagement), because references to memory allocated by the request allocator might be stored outside of the request handler, making this approach not @safe

The plan was/is to eventually disallow storing anything from a HTTPRequest through DIP1000 et al., but as long as that is not done (or possible due to the limitations of DIP1000) the default unfortunately needs to stay less efficient that it could be.

The main point of the allocator, as for any region allocator, is to make many small, short-lived allocations fast by only performing a single more expensive allocation instead, so the comment about being pointless seems a bit odd?

It's well understood but the main point of region allocator is to reuse memory not give it back to parent allocator on each "reset" of the allocation state. That is what vibe.container's allocator does - it frees memory on deallocateAll and I believe this to be wrong as it misses then the 2nd major point in having region allocator. Pointless is probably too harsh a word for this.

Duplicating the RegionListAllocator implementation here instead of modifying the one in vibe-container is rather messy,

I know, in fact I'd rather have vibe container implementation fixed. However, this was to show the gist of changes in one place instead of spreading it out in multiple PRs that have to be connected somehow.

This may only be done for version (VibeManualMemoryManagement), because references to memory allocated by the request allocator might be stored outside of the request handler, making this approach not @safe

This didn't occur to me. We could try per connection region allocator gated by this version then.

Okay, I'll follow up with a PR to vibe.container and then rethink how allocator is used in this branch.

vibe-d/vibe-container#26

Sorry for the late reaction, I missed the vibe-container PR in my notification feed and just stumbled over it now. BTW, there was a severe performance regression in vibe-core (vibe-d/vibe-core#441), so hopefully that also improves the baseline for the normal eventcore based implementation.