Learning resources for std.experimental.allocator

[Chris Wright via Digitalmars-d]

On Thu, 05 Jan 2017 11:09:01 +0000, xtreak wrote:
> Can someone explain me the actual benefits of using this

The target audience is people writing libraries that need to allocate 
memory, where the libraries' target audiences care about performance more 
than most.

GC allocation and scans can be expensive. Far more so when you have to 
deal with interior pointers, which are common in D (thanks to how arrays 
are designed). Real-time programming especially isn't allowed to touch 
the GC in general because it could cause the program to pause for an 
unpredictable amount of time.

There are a lot of other approaches to memory management. You might, for 
instance, have an allocator that just holds a large buffer of memory and 
a pointer to the first free segment of it. You can't free up arbitrary 
segments of memory from it and expect them to be reused. This is 
convenient when you are dealing with a task that allocates its own memory 
and then finishes without sharing that memory anywhere else.

Or you could use malloc, which is better for minimizing memory use and 
amortizes the cost of memory management better than a GC.

If you write your code to use std.experimental.allocator, then other 
people who depend on it can decide what strategy works for them.

The downside is that you must write your code in the least capable way 
available. You can't rely on resources being automatically cleaned up at 
any point because the person might be using an allocator that just calls 
malloc and free.

As for benchmarks, an allocator is just a thin wrapper around malloc/
free, or a thin wrapper around the GC, or the like. The differences 
should be relatively obvious.

There are some other interesting things you can do with this, though, 
regarding tracking how you use memory. Or you could use it to better 
benchmark malloc vs GC for your application.