为什么释放速度慢?

发布于 2024-12-17 17:06:43 字数 223 浏览 0 评论 0原文

我有一个问题,无法在网上找到答案...

我有一个这样声明的集合:

set<unsigned int> MySet

我正在插入用 mersenne twiner 生成的一百万个随机数。随机生成和插入确实很快(一百万个数字大约需要一秒),但释放却非常慢(一分半钟)。

为什么释放这么慢?我没有为该集合使用任何自定义析构函数。

I have a question for which I am unable to find answer on the net...

I have a set declared like this:

set<unsigned int> MySet

I am inserting a million random numbers generated with mersenne twister. Random generation and insertion are really fast (around a second for a million numbers), but deallocation is extremely slow (1 and a half minute).

Why is deallocation so slow? I am not using any custom destructors for the set.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

终陌 2024-12-24 17:06:43

在发布模式下编译代码。

这有两件事。

  1. 它打开了肯定有帮助的优化。
  2. 此外,调试和发布的内存管理库也不同。
    该库的调试版本是为了允许调试而构建的,并且它们维护额外的信息(例如标记已解除分配的内存)。所有这些额外的处理实际上都会花费

    • 两个版本的库的目标完全不同。发布版本肯定针对速度进行了优化,调试版本针对恢复和调试进行了优化。

请注意,此信息是关于 DevStudio 的。

Compile your code in release mode.

This does two things.

  1. It turns on the optimizations which definitely help.
  2. Also the memory management libraries are different for debug and release.
    The debug version of the library are built to allow for debugging and they maintain extra information (like marking de-allocated memory). All this extra processing does actually cost

    • The objective of the two version of the library are completely different. The release version is definitely optimized for speed the debug version is optimized for recovery and debugging.

Note this information is about DevStudio.

暮凉 2024-12-24 17:06:43

可能是因为以取消分配为代价来优化分配更有意义,因为许多应用程序在不取消分配的情况下进行分配,但反之则不然。我自己也看到过类似的模式,在一个混合调用 mallocfree 的应用程序中(而不是同时分配和取消分配)。

我从未编写过堆分配器,所以我不知道是否还有比这更深层次的技术原因。解除分配时,必须找到并合并相邻的空闲块。所以工作是根本不同的。

90 秒 100 万个小 free() 听起来相当慢。我从来没有真正编写过 Windows 程序,所以我不能说这是否异常,但系统应该能够做得更好。

问题的解决方案可能只是在程序退出之前跳过释放对象。您可以尝试从 std::allocator派生自定义分配器unsigned int > 这使得 deallocate 成为无操作。

Probably because it makes more sense to optimize allocation at the expense of deallocation, because many applications allocate without deallocating, but never vice versa. I've seen a similar pattern myself, in an application that mixed calls to malloc and free (as opposed to allocating and deallocating all at once).

I've never written a heap allocator, so I don't know if there's a deeper technical reason than that. When deallocating, adjacent free blocks must be found and coalesced. So the work is just fundamentally different.

90 seconds for 1 million small free()'s sounds quite slow. I've never really programmed Windows so I can't say if that's abnormal, but the system should be able to do much better.

The solution to your problem may be simply to skip freeing the objects before the program exits. You might try deriving a custom allocator from std::allocator< unsigned int > which makes deallocate a no-op.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文