Question

我有一个程序，我将多个缓冲区分配为接收队列的一部分，以便从端口接收消息（UDP协议）。目前缓冲区不是连续的，但现在我正在考虑使它们连续，以便我可以在需要时轻松地将它们拼凑在一起。与重复分配较小的块相比，请求1个大块内存是否不那么可靠/快速。

我正在查看的总大小为1000个2KB缓冲区，因此为2MB。

请不要告诉我应该使用TCP;如果我能，我会。

顺便说一句，我正在使用c ++并使用VS2005进行编译。

Answer 1

分配大块通常比分配多个小块更快。每个分配都有一个开销，因此只需一次大量分配就可以支付一次而不是很多次的开销。

Answer 2

分配单个大块而不是大量较小的块肯定更快。但是，它也有其自身的缺点。当你分配小块时，很明显什么请求拥有什么块。完成后，释放小块。

如果确实分配了一个大块，则需要实现某种分配方案，以便为请求保留大块的范围，并在完成后将它们添加回空闲池。所以这个领域会有开销。如果您有其他要求（正如您所提到的，将某些请求拼接在一起需要为多个请求保留连续区域），您还必须在自定义分配器中实现这些功能。因此，您将为代码添加一定程度的复杂性（和错误）。

Answer 3

1000分配并不差，1000000是真正难看的开销时的数字。

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main ()
{
    int i;
    void* bigPtr;
    void* ptrArray[1000];

    clock_t t1, t2, t3;

    t1 = clock();
    for (i = 0; i < 1000; ++i)
    {
        ptrArray[i] = malloc(2048);
    }
    t2 = clock();

    bigPtr = malloc(i*2048);

    t3 = clock();

    printf("1 big allocation: %.0f ms, %i small allocations = %.0f ms\n",
        difftime(t3, t2), i, difftime(t2, t1));

    return 0;
}

输出：

1 big allocation: 0 ms, 1000 small allocations = 2 ms
1 big allocation: 0 ms, 10000 small allocations = 9 ms
1 big allocation: 0 ms, 100000 small allocations = 80 ms
1 big allocation: 0 ms, 1000000 small allocations = 733 ms

Answer 4

它肯定更快，因为它需要更少的分配/免费操作。我想不出任何理由它或多或少可靠，只要最大的分配大小完全在你的分配器（2MB是）的范围内。

Answer 5

当你有很多小对象时，

自定义分配器可以更快，对于大对象（小对象的数组应该落入这个桶），它不太可能。它们不是为分配大量小物件而设计的。

我不确定我是否希望uint8_t的缓冲区在自定义分配器上分配一个数量级更快。

我不会说更换分配器可能更可靠。你正在取代被证明有用的东西。

如果你有一个固定数量的内存，你可能只想预先分配所有内容，并在它们离线时复制值。我认为这是一个避免这个瓶颈的简单解决方案。

假设它是一个瓶颈。你描述得对吗？

任何更快/可靠的分配多个小块而不是一个大块

5 个答案: