... which has been a trivial wrapper around HeapAlloc for a long time, and the HeapAlloc implementation varies by the Windows version. In particular, Vista+ versions are low-fragmentation heaps and W7+ versions have an outstanding multi-threaded performance.
In other words, deferring to a "MSVC's built-in memory allocator" doesn't make much sense.
And recently (in 2013, I forget about previous versions) the CRT began using the process heap, instead of having its own heap handle. So the malloc/new/std::allocator family is an even thinner wrapper around HeapAlloc in that sense.
(In 2015, we're introducing a little bit of extra trickery though. In std::allocator, we'll highly align large allocations to be friendly to autovectorization. This isn't done at the lower malloc/new levels because they don't get size information at deallocation time, but the std::allocator interface has always required that information even if it was previously ignored. IIRC this buys 15% or so, which makes the back-end devs drool. Our current magic number for "large" is 4 KB, so this basically never affects node-based containers, only stuff like big vectors.)
> In std::allocator, we'll highly align large allocations to be friendly to autovectorization
Ok this and other things you posted here are mighty interesting - do you (or someone else working on this) have (has) a blog where news like this gets announced?
... which has been a trivial wrapper around HeapAlloc for a long time, and the HeapAlloc implementation varies by the Windows version. In particular, Vista+ versions are low-fragmentation heaps and W7+ versions have an outstanding multi-threaded performance.
In other words, deferring to a "MSVC's built-in memory allocator" doesn't make much sense.