7

我正在使用一个内存池类，它重用分配的内存地址和一个包装该类的自定义分配器。以下代码片段为您提供了界面的基本概念。

template<class alloc>
class memory_pool
    : boost::noncopyable,
      public allocator_traits<void>
{
public:
    memory_pool(typename alloc::size_type alloc_size);
    memory_pool(typename alloc::size_type alloc_size, alloc const&);
    template<typename U> memory_pool(typename alloc::size_type alloc_size,
        typename alloc::rebind<U>::other const&);
    virtual ~memory_pool();

    pointer allocate  (); /*throw(std::bad_alloc)*/
    void    collect   ();
    void    deallocate(pointer) throw(); /*noexcept*/
};

pointer allocate()
{/*
    Checks if a suitable chunk of memory is available in a internal linked list.
    If true, then the chunk is returned and the next chunk moves up.
    Otherwise, new memory is allocated by the underlying allocator.
*/}

void deallocate(pointer)
{/*
    Interprets the passed pointer as a chunk of memory and stores it in a linked list.
    Please note that memory isn't actually deallocated.
*/}

void collect()
{/*
    Effectively deallocates the cunks in the linked list.
    This will be called at least once during destruction.
*/}

当然，对这样的东西的需求是有限的。然而，它在您需要的情况下非常有用： - 为一个以非常幼稚的方式使用该分配器的类指定一个分配器类型（例如，避免分配较大的块，即使它是可取的）。- 重复分配和释放相同大小的内存。- 您希望使用分配器的类型非常小（例如，内置类型，如 char、short、int 等）。

从理论上讲，实现可以利用 memory_pool 分配实际分配大小的倍数，每次它需要这样做（来自底层内存管理器）。靠得很近的对象更适合任何缓存和/或预取算法。我已经实现了这样一个内存池，它有一些开销来处理正确的分配、拆分和释放（我们不能释放用户将传递给释放的每个地址。​​我们只需要释放作为我们拥有的每个内存块开头的地址之前已分配）。

我已经使用以下非常简单的代码测试了这两种情况：

std::list<int, allocator<int>> list;

std::clock_t t = std::clock();
for (int i = 0; i < 1 << 16; ++i)
{
    for (int j = 0; j < 1 << 16; ++j)
        list.push_back(j);
    list.unique();
    for (int j = 0; j < 1 << 16; ++j)
        list.pop_back();
}
std::cout << (std::clock() - t) / CLOCKS_PER_SEC << std::endl;

std::list正在调用allocactor::allocate(1, 0)每次push_back调用。unique()确保每个元素都会被触摸并与下一个元素进行比较。然而，结果令人失望。管理按块分配内存池所需的最小开销大于系统获得的任何可能优势。

你能想出一个可以提高性能的场景吗？

编辑： 当然，它比std::allocator.

4

2 回答 2

1

C++0x 更好地支持范围分配器，例如内存池。

分析您的代码。除非您的算法执行非常规则的分配/释放模式，例如 LIFO，否则很难预测这将带来什么优势。

当所有分配的对象大小相同时，编写一个非常快的分配器非常容易。有一次我写了一些类似的东西

template <size_t ObjectSize> class allocator {
    // ...
};

template <typename T> class allocator : public allocator <sizeof (T)> {
    // ...
};

在设计分配器之前，您需要确定将分配什么以及如何分配。答案operator new是“任何事情”和“无论如何”，这就是为什么它有时不是最理想的。如果你不能正确回答这些问题，你的分配器可能不会有很大的改进。

于 2011-07-06T12:57:06.850 回答
0

你能想出一个可以提高性能的场景吗？

执行大量（每秒 10k+）分配和释放的操作将受益于不必每次都遇到复杂的查询来分配/释放，但是，只有在延迟分配/释放到组中的综合节省超过需要处理一个组（基本上，您需要通过每单位节省来摊销该组）。

使用连续内存将有助于任何基于节点/指针的结构，如树（但仅限于一点）。然而，现实世界的好处可能与他们计划的完全不同（或根本不存在！），这就是为什么在创建这样的自定义系统的道路上，你应该分析你的代码并且已经有了一个记住它的使用方式（即：没有必要为分配很少以至于速度增益根本无关紧要的东西制作自定义池分配器）。

然而，这样的东西对于调试来说可能很方便，因为您有一个很好的接口来标记内存以监视泄漏和覆盖/无效写入，因此即使它具有与标准系统相同的性能，您也可以通过其他方式获得收益。

于 2011-07-06T13:13:24.027 回答