为什么释放堆内存比分配它慢得多？
Why deallocating heap memory is much slower than allocating it?
这是一个经验假设（分配比取消分配更快）。
这也是 一个 的原因，我猜，为什么基于堆的存储（如 STL 容器或其他）选择不return 当前系统未使用的内存（这就是 shrink-to-fit 成语诞生的原因）。
当然，我们不应该将“heap”内存与类似“heap”的数据结构混淆。
那么为什么取消分配速度较慢？
它是 Windows 特定的（我在 Win 8.1 上看到它）还是 OS独立?
在使用“new”/“delete”或整个内存时是否会自动涉及某些 C++ 特定的内存管理器。管理完全靠OS？ （我知道 C++11 引入了一些垃圾收集支持，我从来没有真正使用过，最好依赖旧的 stack 和 static 持续时间或自我管理 containers 和 RAII).
此外，在 FOLLY 字符串 的代码中，我看到使用旧的 C 堆分配/释放，它比 C++ 快吗？'new' / '删除'?
P。 S. 请注意问题 不是 关于 虚拟内存 机制，我理解 user-space 程序没有使用真实内存。地址。
这里的问题是堆碎片。用具有显式指针算法的语言编写的程序没有现实的堆碎片整理方法。
如果你的堆是碎片化的，你就不能 return 内存到 OS。 OS，除了虚拟内存，取决于类似 brk(2) 的机制——即您为您将引用的所有内存地址设置一个上限。但是当你分配了一个缓冲区并且在现有边界附近仍在使用时，你不能 return 内存显式地 OS 。程序中所有内存的 99% 是否已被释放都没有关系。
释放不一定比分配慢。但是，您手动释放堆碎片会使分配变得更慢、更复杂。
GC 通过压缩堆来解决这个问题。这样，分配只是为它们递增指针，大量对象不需要释放。
我不确定你的观察结果。我写了下面的程序（在 Linux 上，希望你能把它移植到你的系统上）。
// public domain code
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <errno.h>
#include <string.h>
#include <assert.h>
const unsigned possible_word_sizes[] = {
1, 2, 3, 4, 5,
8, 12, 16, 24,
32, 48, 64, 128,
256, 384, 2048
};
long long totalsize;
// return a calloc-ed array of nbchunks malloced zones of
// somehow random size
void **
malloc_chunks (int nbchunks)
{
const int nbsizes =
(int) (sizeof (possible_word_sizes)
/ sizeof (possible_word_sizes[0]));
void **ad = calloc (nbchunks, sizeof (void *));
if (!ad)
{
perror ("calloc chunks");
exit (EXIT_FAILURE);
};
for (int ix = 0; ix < nbchunks; ix++)
{
unsigned sizindex = random () % nbsizes;
unsigned size = possible_word_sizes[sizindex];
void *zon = malloc (size * sizeof (void *));
if (!zon)
{
fprintf (stderr,
"malloc#%d (%d words) failed (total %lld) %s\n",
ix, size, totalsize, strerror (errno));
exit (EXIT_FAILURE);
}
((int *) zon)[0] = ix;
totalsize += size;
ad[ix] = zon;
}
return ad;
}
void
free_chunks (void **chks, int nbchunks)
{
// first, free the two thirds of chunks in random order
for (int i = 0; 3 * i < 2 * nbchunks; i++)
{
int pix = random () % nbchunks;
if (chks[pix])
{
free (chks[pix]);
chks[pix] = NULL;
}
}
// then, free the rest in reverse order
for (int i = nbchunks - 1; i >= 0; i--)
if (chks[i])
{
free (chks[i]);
chks[i] = NULL;
}
}
int
main (int argc, char **argv)
{
assert (sizeof (int) <= sizeof (void *));
int nbchunks = (argc > 1) ? atoi (argv[1]) : 32768;
if (nbchunks < 128)
nbchunks = 128;
srandom (time (NULL));
printf ("nbchunks=%d\n", nbchunks);
void **chks = malloc_chunks (nbchunks);
clock_t clomall = clock ();
printf ("clomall=%ld totalsize=%lld words\n",
(long) clomall, totalsize);
free_chunks (chks, nbchunks);
clock_t clofree = clock ();
printf ("clofree=%ld\n", (long) clofree);
return 0;
}
我在 Debian/Sid/x86-64 (i3770k, 16Gb) 上用 gcc -O2 -Wall mf.c -o mf 编译了它。我 运行 time ./mf 100000 得到了：
nbchunks=100000
clomall=54162 totalsize=19115681 words
clofree=83895
./mf 100000 0.02s user 0.06s system 95% cpu 0.089 total
在我的系统上 clock 给出 CPU 微秒。如果对 random 的调用可以忽略不计（我不知道是不是）w.r.t。 malloc & free 时间，我倾向于不同意你的观察。 free 似乎是 malloc 的两倍。我的 gcc 是 6.1，我的 libc 是 Glibc 2.22。
请花时间在您的系统上编译上述基准测试并报告时间。
FWIW，我拿了 和
g++ -O3 -march=native jerry.cc -o jerry
time ./jerry; time ./jerry; time ./jerry
给予
alloc time: 1940516
del time: 602203
./jerry 0.00s user 0.01s system 68% cpu 0.016 total
alloc time: 1893057
del time: 558399
./jerry 0.00s user 0.01s system 68% cpu 0.014 total
alloc time: 1818884
del time: 527618
./jerry 0.00s user 0.01s system 70% cpu 0.014 total
分配内存比释放内存更快的断言对我来说有点奇怪，所以我测试了它。我 运行 一个测试，我在 32 字节块中分配了 64MB 的内存（所以 2M 调用 new），我尝试按照分配的相同顺序删除该内存，并在 运行dom命令。我发现线性顺序释放比分配快 3%，运行dom 释放比分配快 10%慢线性分配。
然后我 运行 进行了一项测试，我从 64MB 的已分配内存开始，然后分配了 2M 次新内存或删除了现有内存（在 运行dom 处）。在这里，我发现释放比分配慢 4.3%。
所以，事实证明你是对的 - 释放比分配慢（尽管我不会称它 "much" 慢）。我 怀疑 这与更多 运行dom 访问有关，但除了线性重新分配更快之外我没有其他证据。
回答您的一些问题：
使用 'new' / 'delete' 时是否会自动涉及某些 C++ 特定的内存管理器？
是的。 OS 具有将内存页（通常为 4KB 块）分配给进程的系统调用。将这些页面划分为对象是进程的工作。尝试查找 "GNU Memory Allocator."
我看到使用旧的 C 堆分配/释放，它比 C++ 快吗 'new' / 'delete'？
大多数 C++ new/delete 实现只是在后台调用 malloc 和 free。然而，这不是标准所要求的，因此最好始终对任何特定对象使用相同的分配和释放函数。
我 运行 我使用 Visual Studio 2015 年提供的原生测试框架在 Windows 10 64 位机器上进行测试（测试也是 64 位）。这是代码：
#include "stdafx.h"
#include "CppUnitTest.h"
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
namespace AllocationSpeedTest
{
class Obj32 {
uint64_t a;
uint64_t b;
uint64_t c;
uint64_t d;
};
constexpr int len = 1024 * 1024 * 2;
Obj32* ptrs[len];
TEST_CLASS(UnitTest1)
{
public:
TEST_METHOD(Linear32Alloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
}
TEST_METHOD(Linear32AllocDealloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
for (int i = 0; i < len; ++i) {
delete ptrs[i];
}
}
TEST_METHOD(Random32AllocShuffle)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
int pos = (rand() % (len - i)) + i;
Obj32* temp = ptrs[i];
ptrs[i] = ptrs[pos];
ptrs[pos] = temp;
}
}
TEST_METHOD(Random32AllocShuffleDealloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
int pos = (rand() % (len - i)) + i;
Obj32* temp = ptrs[i];
ptrs[i] = ptrs[pos];
ptrs[pos] = temp;
}
for (int i = 0; i < len; ++i) {
delete ptrs[i];
}
}
TEST_METHOD(Mixed32Both)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
if (rand() % 2) {
ptrs[i] = new Obj32();
}
else {
delete ptrs[i];
}
}
}
TEST_METHOD(Mixed32Alloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
if (rand() % 2) {
ptrs[i] = new Obj32();
}
else {
//delete ptrs[i];
}
}
}
TEST_METHOD(Mixed32Dealloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
if (rand() % 2) {
//ptrs[i] = new Obj32();
}
else {
delete ptrs[i];
}
}
}
TEST_METHOD(Mixed32Neither)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
if (rand() % 2) {
//ptrs[i] = new Obj32();
}
else {
//delete ptrs[i];
}
}
}
};
}
这是几次运行的原始结果。所有数字均以毫秒为单位。
我和@Basile 有很多相同的想法：我想知道你的基本假设是否真的（甚至接近）正确。由于您标记了 C++ 问题，我改为用 C++ 编写了一个快速基准测试。
#include <vector>
#include <iostream>
#include <numeric>
#include <chrono>
#include <iomanip>
#include <locale>
int main() {
std::cout.imbue(std::locale(""));
using namespace std::chrono;
using factor = microseconds;
auto const size = 2000;
std::vector<int *> allocs(size);
auto start = high_resolution_clock::now();
for (int i = 0; i < size; i++)
allocs[i] = new int[size];
auto stop = high_resolution_clock::now();
auto alloc_time = duration_cast<factor>(stop - start).count();
start = high_resolution_clock::now();
for (int i = 0; i < size; i++)
delete[] allocs[i];
stop = high_resolution_clock::now();
auto del_time = duration_cast<factor>(stop - start).count();
std::cout << std::left << std::setw(20) << "alloc time: " << alloc_time << " uS\n";
std::cout << std::left << std::setw(20) << "del time: " << del_time << " uS\n";
}
我还在 Windows 上使用 VC++ 而不是 Linux 上的 gcc。但结果并没有太大不同：释放内存所花费的时间比分配内存所花费的时间要少得多。这是三个连续运行的结果。
alloc time: 2,381 uS
del time: 1,429 uS
alloc time: 2,764 uS
del time: 1,592 uS
alloc time: 2,492 uS
del time: 1,442 uS
不过，我要警告，分配和释放（主要）由标准库处理，因此这在一个标准库和另一个标准库之间可能不同（即使使用相同的编译器）。我还注意到，如果这在多线程代码中有所改变，我不会感到惊讶。虽然这实际上并不正确，但似乎有一些作者误解了在多线程环境中释放需要锁定堆以进行独占访问。这可以避免，但这样做的方法不一定立即显而易见。
分配小内存块时，您指定的块大小直接映射到该大小的子分配器，通常表示为包含相同大小记录的 "slab" 内存，以避免内存碎片。这可以非常快，类似于数组访问。但是释放这样的块并不是那么简单，因为您正在传递一个指向未知大小的内存的指针，需要额外的工作来确定它属于哪个 slab，然后才能将块返回到适当的位置。
当您分配大块虚拟内存时，会在您的进程中设置一个内存页面范围 space 而无需实际将任何物理内存映射到它，这需要很少的工作来完成。但是释放这么大的块可能需要更多的工作，因为释放的指针必须首先与该范围的页表匹配，然后遍历它所跨越的内存范围的所有页面条目，并释放所有物理由中间页面错误分配给该范围的内存页面。
当然，这方面的细节会根据所使用的实现而有所不同，但原理基本相同：已知块大小的内存分配比释放指向未知大小的内存块的指针更省力.我对此的了解直接来自于我开发高性能商业级 RAII 内存分配器的经验。
我还应该指出，由于每个堆分配都有一个匹配和相应的释放，这对操作代表一个分配周期，即作为一个硬币的两个面。它们的执行时间可以一起精确测量，但单独测量很难确定，因为它因块大小、类似大小的先前 activity、缓存和其他操作考虑因素而有很大差异。但最终，allocate/free 差异可能并不重要，因为你不能缺一不可。
这是一个经验假设（分配比取消分配更快）。
这也是 一个 的原因，我猜，为什么基于堆的存储（如 STL 容器或其他）选择不return 当前系统未使用的内存（这就是 shrink-to-fit 成语诞生的原因）。
当然，我们不应该将“heap”内存与类似“heap”的数据结构混淆。
那么为什么取消分配速度较慢？
它是 Windows 特定的（我在 Win 8.1 上看到它）还是 OS独立?
在使用“new”/“delete”或整个内存时是否会自动涉及某些 C++ 特定的内存管理器。管理完全靠OS？ （我知道 C++11 引入了一些垃圾收集支持，我从来没有真正使用过，最好依赖旧的 stack 和 static 持续时间或自我管理 containers 和 RAII).
此外，在 FOLLY 字符串 的代码中，我看到使用旧的 C 堆分配/释放，它比 C++ 快吗？'new' / '删除'?
P。 S. 请注意问题 不是 关于 虚拟内存 机制，我理解 user-space 程序没有使用真实内存。地址。
这里的问题是堆碎片。用具有显式指针算法的语言编写的程序没有现实的堆碎片整理方法。
如果你的堆是碎片化的，你就不能 return 内存到 OS。 OS，除了虚拟内存，取决于类似 brk(2) 的机制——即您为您将引用的所有内存地址设置一个上限。但是当你分配了一个缓冲区并且在现有边界附近仍在使用时，你不能 return 内存显式地 OS 。程序中所有内存的 99% 是否已被释放都没有关系。
释放不一定比分配慢。但是，您手动释放堆碎片会使分配变得更慢、更复杂。
GC 通过压缩堆来解决这个问题。这样，分配只是为它们递增指针，大量对象不需要释放。
我不确定你的观察结果。我写了下面的程序（在 Linux 上，希望你能把它移植到你的系统上）。
// public domain code
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <errno.h>
#include <string.h>
#include <assert.h>
const unsigned possible_word_sizes[] = {
1, 2, 3, 4, 5,
8, 12, 16, 24,
32, 48, 64, 128,
256, 384, 2048
};
long long totalsize;
// return a calloc-ed array of nbchunks malloced zones of
// somehow random size
void **
malloc_chunks (int nbchunks)
{
const int nbsizes =
(int) (sizeof (possible_word_sizes)
/ sizeof (possible_word_sizes[0]));
void **ad = calloc (nbchunks, sizeof (void *));
if (!ad)
{
perror ("calloc chunks");
exit (EXIT_FAILURE);
};
for (int ix = 0; ix < nbchunks; ix++)
{
unsigned sizindex = random () % nbsizes;
unsigned size = possible_word_sizes[sizindex];
void *zon = malloc (size * sizeof (void *));
if (!zon)
{
fprintf (stderr,
"malloc#%d (%d words) failed (total %lld) %s\n",
ix, size, totalsize, strerror (errno));
exit (EXIT_FAILURE);
}
((int *) zon)[0] = ix;
totalsize += size;
ad[ix] = zon;
}
return ad;
}
void
free_chunks (void **chks, int nbchunks)
{
// first, free the two thirds of chunks in random order
for (int i = 0; 3 * i < 2 * nbchunks; i++)
{
int pix = random () % nbchunks;
if (chks[pix])
{
free (chks[pix]);
chks[pix] = NULL;
}
}
// then, free the rest in reverse order
for (int i = nbchunks - 1; i >= 0; i--)
if (chks[i])
{
free (chks[i]);
chks[i] = NULL;
}
}
int
main (int argc, char **argv)
{
assert (sizeof (int) <= sizeof (void *));
int nbchunks = (argc > 1) ? atoi (argv[1]) : 32768;
if (nbchunks < 128)
nbchunks = 128;
srandom (time (NULL));
printf ("nbchunks=%d\n", nbchunks);
void **chks = malloc_chunks (nbchunks);
clock_t clomall = clock ();
printf ("clomall=%ld totalsize=%lld words\n",
(long) clomall, totalsize);
free_chunks (chks, nbchunks);
clock_t clofree = clock ();
printf ("clofree=%ld\n", (long) clofree);
return 0;
}
我在 Debian/Sid/x86-64 (i3770k, 16Gb) 上用 gcc -O2 -Wall mf.c -o mf 编译了它。我 运行 time ./mf 100000 得到了：
nbchunks=100000
clomall=54162 totalsize=19115681 words
clofree=83895
./mf 100000 0.02s user 0.06s system 95% cpu 0.089 total
在我的系统上 clock 给出 CPU 微秒。如果对 random 的调用可以忽略不计（我不知道是不是）w.r.t。 malloc & free 时间，我倾向于不同意你的观察。 free 似乎是 malloc 的两倍。我的 gcc 是 6.1，我的 libc 是 Glibc 2.22。
请花时间在您的系统上编译上述基准测试并报告时间。
FWIW，我拿了
g++ -O3 -march=native jerry.cc -o jerry
time ./jerry; time ./jerry; time ./jerry
给予
alloc time: 1940516
del time: 602203
./jerry 0.00s user 0.01s system 68% cpu 0.016 total
alloc time: 1893057
del time: 558399
./jerry 0.00s user 0.01s system 68% cpu 0.014 total
alloc time: 1818884
del time: 527618
./jerry 0.00s user 0.01s system 70% cpu 0.014 total
分配内存比释放内存更快的断言对我来说有点奇怪，所以我测试了它。我 运行 一个测试，我在 32 字节块中分配了 64MB 的内存（所以 2M 调用 new），我尝试按照分配的相同顺序删除该内存，并在 运行dom命令。我发现线性顺序释放比分配快 3%，运行dom 释放比分配快 10%慢线性分配。
然后我 运行 进行了一项测试，我从 64MB 的已分配内存开始，然后分配了 2M 次新内存或删除了现有内存（在 运行dom 处）。在这里，我发现释放比分配慢 4.3%。
所以，事实证明你是对的 - 释放比分配慢（尽管我不会称它 "much" 慢）。我 怀疑 这与更多 运行dom 访问有关，但除了线性重新分配更快之外我没有其他证据。
回答您的一些问题：
使用 'new' / 'delete' 时是否会自动涉及某些 C++ 特定的内存管理器？
是的。 OS 具有将内存页（通常为 4KB 块）分配给进程的系统调用。将这些页面划分为对象是进程的工作。尝试查找 "GNU Memory Allocator."
我看到使用旧的 C 堆分配/释放，它比 C++ 快吗 'new' / 'delete'？
大多数 C++ new/delete 实现只是在后台调用 malloc 和 free。然而，这不是标准所要求的，因此最好始终对任何特定对象使用相同的分配和释放函数。
我 运行 我使用 Visual Studio 2015 年提供的原生测试框架在 Windows 10 64 位机器上进行测试（测试也是 64 位）。这是代码：
#include "stdafx.h"
#include "CppUnitTest.h"
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
namespace AllocationSpeedTest
{
class Obj32 {
uint64_t a;
uint64_t b;
uint64_t c;
uint64_t d;
};
constexpr int len = 1024 * 1024 * 2;
Obj32* ptrs[len];
TEST_CLASS(UnitTest1)
{
public:
TEST_METHOD(Linear32Alloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
}
TEST_METHOD(Linear32AllocDealloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
for (int i = 0; i < len; ++i) {
delete ptrs[i];
}
}
TEST_METHOD(Random32AllocShuffle)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
int pos = (rand() % (len - i)) + i;
Obj32* temp = ptrs[i];
ptrs[i] = ptrs[pos];
ptrs[pos] = temp;
}
}
TEST_METHOD(Random32AllocShuffleDealloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
int pos = (rand() % (len - i)) + i;
Obj32* temp = ptrs[i];
ptrs[i] = ptrs[pos];
ptrs[pos] = temp;
}
for (int i = 0; i < len; ++i) {
delete ptrs[i];
}
}
TEST_METHOD(Mixed32Both)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
if (rand() % 2) {
ptrs[i] = new Obj32();
}
else {
delete ptrs[i];
}
}
}
TEST_METHOD(Mixed32Alloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
if (rand() % 2) {
ptrs[i] = new Obj32();
}
else {
//delete ptrs[i];
}
}
}
TEST_METHOD(Mixed32Dealloc)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
if (rand() % 2) {
//ptrs[i] = new Obj32();
}
else {
delete ptrs[i];
}
}
}
TEST_METHOD(Mixed32Neither)
{
for (int i = 0; i < len; ++i) {
ptrs[i] = new Obj32();
}
srand(0);
for (int i = 0; i < len; ++i) {
if (rand() % 2) {
//ptrs[i] = new Obj32();
}
else {
//delete ptrs[i];
}
}
}
};
}
这是几次运行的原始结果。所有数字均以毫秒为单位。
我和@Basile 有很多相同的想法：我想知道你的基本假设是否真的（甚至接近）正确。由于您标记了 C++ 问题，我改为用 C++ 编写了一个快速基准测试。
#include <vector>
#include <iostream>
#include <numeric>
#include <chrono>
#include <iomanip>
#include <locale>
int main() {
std::cout.imbue(std::locale(""));
using namespace std::chrono;
using factor = microseconds;
auto const size = 2000;
std::vector<int *> allocs(size);
auto start = high_resolution_clock::now();
for (int i = 0; i < size; i++)
allocs[i] = new int[size];
auto stop = high_resolution_clock::now();
auto alloc_time = duration_cast<factor>(stop - start).count();
start = high_resolution_clock::now();
for (int i = 0; i < size; i++)
delete[] allocs[i];
stop = high_resolution_clock::now();
auto del_time = duration_cast<factor>(stop - start).count();
std::cout << std::left << std::setw(20) << "alloc time: " << alloc_time << " uS\n";
std::cout << std::left << std::setw(20) << "del time: " << del_time << " uS\n";
}
我还在 Windows 上使用 VC++ 而不是 Linux 上的 gcc。但结果并没有太大不同：释放内存所花费的时间比分配内存所花费的时间要少得多。这是三个连续运行的结果。
alloc time: 2,381 uS
del time: 1,429 uS
alloc time: 2,764 uS
del time: 1,592 uS
alloc time: 2,492 uS
del time: 1,442 uS
不过，我要警告，分配和释放（主要）由标准库处理，因此这在一个标准库和另一个标准库之间可能不同（即使使用相同的编译器）。我还注意到，如果这在多线程代码中有所改变，我不会感到惊讶。虽然这实际上并不正确，但似乎有一些作者误解了在多线程环境中释放需要锁定堆以进行独占访问。这可以避免，但这样做的方法不一定立即显而易见。
分配小内存块时，您指定的块大小直接映射到该大小的子分配器，通常表示为包含相同大小记录的 "slab" 内存，以避免内存碎片。这可以非常快，类似于数组访问。但是释放这样的块并不是那么简单，因为您正在传递一个指向未知大小的内存的指针，需要额外的工作来确定它属于哪个 slab，然后才能将块返回到适当的位置。
当您分配大块虚拟内存时，会在您的进程中设置一个内存页面范围 space 而无需实际将任何物理内存映射到它，这需要很少的工作来完成。但是释放这么大的块可能需要更多的工作，因为释放的指针必须首先与该范围的页表匹配，然后遍历它所跨越的内存范围的所有页面条目，并释放所有物理由中间页面错误分配给该范围的内存页面。
当然，这方面的细节会根据所使用的实现而有所不同，但原理基本相同：已知块大小的内存分配比释放指向未知大小的内存块的指针更省力.我对此的了解直接来自于我开发高性能商业级 RAII 内存分配器的经验。
我还应该指出，由于每个堆分配都有一个匹配和相应的释放，这对操作代表一个分配周期，即作为一个硬币的两个面。它们的执行时间可以一起精确测量，但单独测量很难确定，因为它因块大小、类似大小的先前 activity、缓存和其他操作考虑因素而有很大差异。但最终，allocate/free 差异可能并不重要，因为你不能缺一不可。