启动线程后首次调用 malloc 需要很长时间

Question

首先，我将声明我无法使用示例程序复制该行为。这有点困难，因为我不确定是什么导致了这个问题。

我已经提供了一些代码来给出我想要描述的内容的一种心理地图。本质上，如标题中所述，我们看到线程第一次调用大小为 >= 1KB 的 malloc 需要很长时间。

#include <iostream>
#include <thread>
#include <vector>

#include <ctime>
#include <ratio>
#include <chrono>


using namespace std::chrono;


class myClass {
public:
    myClass();
    void someFunction();
};

myClass::myClass() {;}

void myClass::someFunction() {
    high_resolution_clock::time_point t1 = high_resolution_clock::now();

    int *arr1 = (int*)malloc(sizeof(int) * 1000);

    high_resolution_clock::time_point t2 = high_resolution_clock::now();

    int *arr2 = (int*)malloc(sizeof(int) * 1000);

    high_resolution_clock::time_point t3 = high_resolution_clock::now();

    duration<double, std::milli> time_span1 = t2 - t1;
    duration<double, std::milli> time_span2 = t3 - t2;

    std::cout << "first alloc took" << time_span1.count() << "milliseconds" << std::endl;
    std::cout << "second alloc took" << time_span2.count() << "milliseconds" << std::endl;
}


int main() {
    myClass obj1;


    std::vector<std::thread> ThreadManager(1);

    ThreadManager[0] = std::thread(&myClass::someFunction, obj1);

    ThreadManager[0].join();
}

同样，此示例中不存在此问题。此示例显示已启动线程中的第一个 malloc 比第二个花费的时间更长。但是，在我的机器上，第一个 malloc 的执行大约需要 0.05 毫秒，这对我来说不是问题。第二次调用的“加速”很容易归因于 ILP 之类的东西。

在我正在进行的项目中，第一个 malloc 的执行时间要差得多（5-10ms）。这仅在启动线程后第一次调用 malloc 时发生，前提是请求的内存量不可忽略 (>= ~1KB)。我注意到仅启动一个线程时存在此问题（如示例代码中所示），因此它似乎不是同步问题。该问题可能与碎片有关，但如果我在启动线程之前请求相同数量的内存，我们看不到性能问题。此外，项目中的大多数分配都是通过一次请求大块的分配器完成的，我认为这应该可以减少碎片问题的可能性。此外，我已经测试了主程序的多个输入，并且发生问题的输入集是确定性的——这对我来说意味着它与运行时的复杂性无关。我应该提一下，我正在做的项目规模适中（几千行），std::thread 的可调用对象属于一个比较大的类。

基本上，我不知道是什么导致了这个问题，我想知道是否有人以前见过类似的东西——如果有，他们是如何解决的:)

编辑： 经过进一步调查，性能错误至少与同步间接相关。 malloc 使用多个 arena 来处理多个同步调用。这些竞技场的数量可以通过调用mallopt 来更改。通过mallopt(M_ARENA_MAX, 1)将arenas的最大数量更改为一个后，第一次调用malloc的性能已经恢复正常。也就是说，由于应用程序是多线程的，我想使用更多的 arena，当我将最大值更改为 2 时，开销会返回（第一次调用 malloc 需要 5-10 毫秒）。我想知道如何增加竞技场的数量会导致这样的开销。

Answer 1

这可能是也可能不是同步问题。 malloc 的语言实现可能是管理每个线程或每个处理器的空闲列表，或者可能有一个可能需要同步的内存池。因此，不了解剩余代码（实际上是整个应用程序和运行时）的作用会导致猜测。

同时，用户模式内存管理器做了两件事：一是确保操作系统分配（也称为“使有效”）一部分虚拟地址空间，二是细分该部分以响应到 malloc() 调用。

因此，可以想象（推测）第一次调用 malloc 从操作系统请求虚拟地址空间。不是便宜的电话。第二次调用可能会简单地将指针返回到操作系统返回的空间中，从而使其更快。

再次，猜测。