On 7/27/21 2:46 PM, Jason McKesson wrote:

There is nothing especially "compile-time" about your allocator. And I
don't see why I would use it when
`std::pmr::unsycnhronized_pool_resource` exists. And if the virtual
overhead of the type really bothers you, you can easily wrap it in a
proper allocator type that hard-codes the resource type, so that
devirtualization will take place.

Also, shouldn't the goal be to improve performance? Beating the
generic memory allocator could be a means to achieve that, in certain
cases, but wouldn't it make more sense to identify specific poorly
performing cases and target them? Your proposal is a solution in
search of a problem.

So upon further investigations, by comparing it with boost::fast_pool_allocator, cache_alloc:

- wins the 1st race by far (straight allocations);

- equals the 2nd one (allocs + deallocs);

- fails the 3rd one because of the destructor.

https://github.com/philippeb8/cache_alloc/blob/main/README.md

I'm not sure yet what's wrong with the destructor yet but if I find anything valuable down the road I'll let you know.

I've got the correct implementation now as I'm using my own list, and removed the unrealistic >= 10 MB buffers so the complexity remains constant but the allocation routines are more cpu cycle intensive so there is no big difference with boost::fast_pool_allocator anymore as the results got "sift":

https://github.com/philippeb8/cache_alloc/blob/main/README.md

So anyway if I can get anything better I'll let you know.

Regards,

--

Phil Bouchard
Founder & CTO
C.: (819) 328-4743