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.
