Hi, The pool and the suballocator have several things in common , but they are differents. The next paragraphs is a part of a previous message sent with the countertree tag, where I describe it “In the allocator process we have two parts: - First, from where and how obtain the memory the allocator. - Second How dispatch the memory to the data structure. The suballocator is the second part with a big number of fixed size elements data structures ( STL list, set , multiset, map and multimap). About the suballocator. It is a simple layer over the allocator. It have the same interface. The data structure received a suballocator as template parameter. But the suballocator use internally an allocator. It request a big chuck of memory to the allocator , and manage in a fast and easy way. When a chuck of memory is unused by the data structure, is returned to the allocator. Usually, that big chucks of memory are returned to the Operating System from the allocator , and this reduce the memory consumption of the program. You can see this , running the benchmark_allocator.cpp. The suballocator run over ANY allocator with the STL allocator interface. It don't take care about the kind of allocator or the origin of the memory. If you want to know more about the algorithm of the suballocator, in the documentation , in the point 5.2 you have a document with a description of the data structure and algorithms.” You have a more detailed information in the documentation http://dl.dropbox.com/u/8437476/works/countertree/doc/index.html I need the source of the memory, and the pool library is an excellent option. I need to study in deep, for to know if the pool have all I need for the next extension of the suballocator . If I need something, or have any idea or suggestion , I will comment you. The dispatching of a big number of fixed size elements, have different problems that the dispatching of variable size elements. In the Boost library you have excellent allocators as fast pool allocator. But all of them present a problem. When you deallocate all the elements, they don't return the memory used, and it is always the highest used. The suballocator request chuck of memory to the allocator , but when they are unused, return inmediately to the allocator , and this to the operating system, decreasing the memory used by the program, as you can see in the suballocator benchmarks in the documentation. This problem is well described in the suballocator page in the countertree documentation. ( It's only 1 page, less than 5 minutes for to read) I think, the pool library and the suballocator are complementary in many things, and I am sure, you can be useful to me and perhaps I can be useful to you. Joining ideas, we can be more useful to the Boost community Sincerely yours Francisco Tapia