处理导致性能问题的deque块大小

Dealing with deque block size causing performance issues

本文关键字：deque 问题 性能 处理      更新时间：2023-10-16

在性能关键代码中使用过'deque'的人可能已经注意到(至少在VS2010附带的STL中)块大小为16字节。这是VS2010附带的头文件的实际片段:

#define _DEQUESIZ   (sizeof (value_type) <= 1 ? 16 
    : sizeof (value_type) <= 2 ? 8 
    : sizeof (value_type) <= 4 ? 4 
    : sizeof (value_type) <= 8 ? 2 
    : 1)    /* elements per block (a power of 2) */

这不是新信息，请参阅关于deque's额外的间接说明，以获得有关此decl为什么会导致性能问题的更多详细信息。

我想在各种算法中使用deque，但如果我被限制在这个实现中就不使用了。规避这个问题的最好方法是什么?

1)使用另一个没有此问题的容器。如果有，谁能给我指出一个没有GNU许可证限制的?

2)创建一个新的容器类来解决这个限制。这个新的容器类不属于std命名空间。

3)在'deque'头文件中编辑_DEQUESIZ定义。在我看来，我认为这是合法的，因为_DEQUESIZ的确切规范不是STL定义的deque概念的一部分。

4)给deque(和相关的迭代器类)添加一个额外的模板形参，以允许在编译时指定块大小。这个参数将默认为_DEQUESIZ的当前定义。我几乎拒绝这个解决方案，因为现在我的代码使用这种标准化的STL是不可移植的。

5)游说国会改变STL，这样我就可以愉快地使用'deque'而不会出现性能问题。在我看来，这可能比目前的财政悬崖辩论更成功。顺便说一句，我是加拿大人，所以整个众议院+参议院+总统的繁文缛节让人困惑。

不是真正的答案，但是对于注释来说太长了:

如果您担心性能，我不建议您编写新的容器类。通常，STL实现基于它们所针对的特定编译器的实现细节使用不可移植的优化，而您通常无法这样做。我曾经试过自己重写一些非常简单的STL算法，执行速度大约是STL算法的一半。

更改_DEQUESIZ可能会在不可预见的地方导致性能问题，因为其他代码可能会针对原始值进行优化。同样，当您为特定编译器编写代码时，您可以进行这种不可移植的优化。不仅如此:你甚至可能会破坏一些依赖于_DEQUESIZ实际值的代码。

总之，在我看来，只有你的选项1是可行的。不幸的是，我不知道有什么好的选择;

我倾向于1).

标准库的libc++实现是在一个非常自由的许可下发布的，事实上足够自由，如果你的编译器阻塞它，你可以调整它以适应它(它是围绕Clang设计的，它比VS 2010更具一致性和c++ 11意识)。您只需要保留许可证。

作为选项1的解决方案)我想建议从我的库中找到sfl::segmented_vector容器，您可以在GitHub找到:https://github.com/slavenf/sfl-library

此容器与std::deque类似。块(我称之为段)的大小在编译时作为模板参数指定。

相关文章：