On 13/04/12 20:35, Francisco José Tapia wrote:
The allocators of GCC 4.6 and CLANG/LLVM 3.0 have problems for to return memory to the operating systems. If you create a std::set with 30.000.000 elements, check the memory used by the program, delete all the elements and check the memory. You see the same memory used by the program in the two checks
If you do the same in Visual Studio 10, the allocator collect the memory and return to the operating System, and the memory of the program downs a lot. But is a byte slower than the GCC allocator
In the benchmarks, the suballocator with the std::allocator with GCC4.6, CLANG 3.0 and VS10, is more than 3 times faster than the std:allocator alone.
But with GCC and CLANG, the std::allocator is capable to return the memory returned from the suballocator, to the operating system and the memory used by the program downs.
This principle is referred to as a pool allocator, memory is kept rather than given back to the operating system. This results in faster memory management, but of course means that you're not giving the memory for other processes to use. It is well known that GCC uses a pool allocator by default while MSVC does not; note that there is an option in GCC to disable this. I still don't see how your contribution fits into this. Note Boost already has fast pool allocators. This is still different from a region allocator, because in that scenario all memory allocations come from the same pool. The principle of a region allocator is to have a pool for each container.