为什么迭代器调试在调试版本中会减慢 std::unordered_map 200 倍?
Why does iterator debugging slow std::unordered_map 200x in debug builds?
我知道代码会更慢,但为什么这么多?如何编码以避免这种减速?
std::unordered_map 在内部使用其他容器,这些容器使用迭代器。构建调试时,默认情况下为 _ITERATOR_DEBUG_LEVEL=2。这将打开迭代器调试。有时我的代码没有受到太大影响,有时它运行得非常慢。
我可以通过在预处理器>>预处理器定义的项目属性中设置 _ITERATOR_DEBUG_LEVEL=0 来加快我的示例>> C++>>。但正如此链接所暗示的那样,我无法在我的实际项目中这样做。就我而言,我与MSVCMRTD.lib发生冲突,其中包含使用_ITERATOR_DEBUG_LEVEL=2构建的std::basic_string。我知道我可以通过静态链接到 CRT 来解决此问题。但是,如果我可以修复代码,我宁愿不要这样做,这样就不会出现问题。
我可以做出改变,改善这种情况。但我只是在尝试一些事情,而不明白它们为什么有效。例如,按原样,前 1000 个刀片全速工作。但是如果我将O_BYTE_SIZE更改为 1,则第一个插入与其他所有内容一样慢。这看起来像是一个很小的变化(不一定是一个好的改变)。
这个,这个,这个也揭示了一些,但不要回答我的问题。
我正在使用Visual Studio 2010(这是遗留代码。我创建了一个 Win32 控制台应用并添加了此代码。
主.cpp
#include "stdafx.h"
#include "OString.h"
#include "OTHashMap.h"
#include <cstdio>
#include <ctime>
#include <iostream>
// Hash and equal operators for map
class CRhashKey {
public:
inline unsigned long operator() (const OString* a) const { return a->hash(); }
};
class CReqKey {
public:
inline bool operator() (const OString& x, const OString& y) const { return strcmp(x.data(),y.data()) != 0; }
inline bool operator() (const OString* x, const OString& y) const { return operator()(*x,y); }
inline bool operator() (const OString& x, const OString* y) const { return operator()(x,*y); }
inline bool operator() (const OString* x, const OString* y) const { return operator()(*x,*y); }
};
int _tmain(int argc, _TCHAR* argv[])
{
const int CR_SIZE = 1020007;
CRhashKey h;
OTPtrHashMap2<OString, int, CRhashKey, CReqKey> *code_map =
new OTPtrHashMap2 <OString, int, CRhashKey, CReqKey>(h, CR_SIZE);
const clock_t begin_time = clock();
for (int i=1; i<=1000000; ++i)
{
char key[10];
sprintf(key, "%d", i);
code_map->insert(new OString(key), new int(i));
//// Check hash values
//OString key2(key);
//std::cout << i << "t" << key2.hash() << std::endl;
// Check timing
if ((i % 100) == 0)
{
std::cout << i << "t" << float(clock() - begin_time) / CLOCKS_PER_SEC << std::endl;
}
}
std::cout << "Press enter to exit" << std::endl;
char buf[256];
std::cin.getline(buf, 256);
return 0;
}
OTHashMap.h
#pragma once
#include <fstream>
#include <unordered_map>
template <class K, class T, class H, class EQ>
class OTPtrHashMap2
{
typedef typename std::unordered_map<K*,T*,H,EQ> OTPTRHASHMAP_INTERNAL_CONTAINER;
typedef typename OTPTRHASHMAP_INTERNAL_CONTAINER::iterator OTPTRHASHMAP_INTERNAL_ITERATOR;
public:
OTPtrHashMap2(const H& h, size_t defaultCapacity) : _hashMap(defaultCapacity, h) {}
bool insert(K* key, T* val)
{
std::pair<OTPTRHASHMAP_INTERNAL_ITERATOR,T> retVal = _hashMap.insert(std::make_pair<K*,T*>(key, val));
return retVal.second != NULL;
}
OTPTRHASHMAP_INTERNAL_CONTAINER _hashMap;
private:
};
OString.h
#pragma once
#include <string>
class OString
{
public:
OString(const std::string& s) : _string (s) { }
~OString(void) {}
static unsigned hash(const OString& s) { return unsigned (s.hash()); }
unsigned long hash() const
{
unsigned hv = static_cast<unsigned>(length());
size_t i = length() * sizeof(char) / sizeof(unsigned);
const char * p = data();
while (i--) {
unsigned tmp;
memcpy(&tmp, p, sizeof(unsigned));
hashmash(hv, tmp);
p = p + sizeof(unsigned);
}
if ((i = length() * sizeof(char) % sizeof(unsigned)) != 0) {
unsigned h = 0;
const char* c = reinterpret_cast<const char*>(p);
while (i--)
{
h = ((h << O_BYTE_SIZE*sizeof(char)) | *c++);
}
hashmash(hv, h);
}
return hv;
}
const char* data() const { return _string.c_str(); }
size_t length() const { return _string.length(); }
private:
std::string _string;
//static const unsigned O_BYTE_SIZE = 1;
static const unsigned O_BYTE_SIZE = 8;
static const unsigned O_CHASH_SHIFT = 5;
inline void hashmash(unsigned& hash, unsigned chars) const
{
hash = (chars ^
((hash << O_CHASH_SHIFT) |
(hash >> (O_BYTE_SIZE*sizeof(unsigned) - O_CHASH_SHIFT))));
}
};
我找到了足够的答案。碰撞是减速的根源。
编辑 2: -- 另一个修复方法是在 main 的 #include 周围添加它.cpp --
// Iterator debug checking makes the Microsoft implementation of std containers
// *very* slow in debug builds for large containers. It must only be undefed around
// STL includes. Otherwise we get linker errors from the debug C runtime library,
// which was built with _ITERATOR_DEBUG_LEVEL set to 2.
#ifdef _DEBUG
#undef _ITERATOR_DEBUG_LEVEL
#endif
#include <unordered_map>
#ifdef _DEBUG
#define _ITERATOR_DEBUG_LEVEL 2
#endif
编辑: -- 修复程序是切换到 boost::unordered_map. --
std::unordered_map 在
_Hash包含这个(高度缩写)
template<...>
class _Hash
{
typedef list<typename _Traits::value_type, ...> _Mylist;
typedef vector<iterator, ... > _Myvec;
_Mylist _List; // list of elements, must initialize before _Vec
_Myvec _Vec; // vector of list iterators, begin() then end()-1
};
所有值都存储在_List中。
_Vec是迭代器进入_List的向量。它将_List划分为多个桶。_Vec有一个迭代器到每个存储桶的开头和结尾。因此,如果映射有 1M 个存储桶(不同的键哈希),_Vec有 2M 个迭代器。
将键/值对插入到映射中时,通常会创建一个新存储桶。该值被推到列表的开头。键的哈希是放置两个新迭代器的_Vec位置。这很快,因为它们指向列表的开头。
如果存储桶已存在,则必须在 _List 中的现有值旁边插入新值。这需要在列表中间插入一个项目。必须更新现有迭代器。显然,当启用迭代器调试时,这需要大量工作。代码<列表中>,但我没有逐步完成它。列表中>
为了了解工作量,我使用了一些无意义的哈希函数,这些函数使用起来很糟糕,但在插入时会产生很多冲突或很少的冲突。
已添加到 OString.h
static unsigned hv2;
// Never collides. Always uses the next int as the hash
unsigned long hash2() const
{
return ++hv2;
}
// Almost never collides. Almost always gets the next int.
// Gets the same int 1 in 200 times.
unsigned long hash3() const
{
++hv2;
unsigned long lv = (hv2*200UL)/201UL;
return (unsigned)lv;
}
// A best practice hash
unsigned long hash4() const
{
std::hash<std::string> hasher;
return hasher(_string);
}
// Always collides. Everything into bucket 0.
unsigned long hash5() const
{
return 0;
}
添加到主.cpp
// Hash and equal operators for map
class CRhashKey {
public:
//inline unsigned long operator() (const OString* a) const { return a->hash(); }
//inline unsigned long operator() (const OString* a) const { return a->hash2(); }
//inline unsigned long operator() (const OString* a) const { return a->hash3(); }
//inline unsigned long operator() (const OString* a) const { return a->hash4(); }
inline unsigned long operator() (const OString* a) const { return a->hash5(); }
};
unsigned OString::hv2 = 0;
结果是戏剧性的。没有现实的哈希是行不通的。
- hash2 - 永不碰撞 - 15.3 秒内插入 1M
- hash3 - 几乎从不 - 1M 在 206 秒内插入
- hash4 - 最佳实践 - 在 132 秒内完成 100k 次插入,并且随着碰撞越来越频繁而变慢。 1M 插入需要> 1 小时
- hash5 - 始终碰撞 - 48 秒内插入 1k 次,或 ~13 小时内插入 1M 次
我的选择是
- 发布构建,调试符号,优化关闭,如退休忍者建议的那样
- 静态链接到 MSVCMRTD,以便我可以关闭_ITERATOR_DEBUG_LEVEL。还解决了其他一些类似的问题。
- 从unordered_map向量更改为排序向量。
- 别的。欢迎提出建议。
- 当回溯以零开始时,如何调试崩溃
- 在linux上调试巨大的C++项目
- 为什么使用__LINE_的代码在发布模式下在MSVC下编译,而不是在调试模式下
- 如何针对特定情况调试和修复此双自由内存损坏问题
- 正在VS调试器中监视映射条目
- 使用调试/崩溃报告将应用程序部署到客户端
- VC++本机单元测试,找不到调试符号
- 如何在C++生成器中禁用"使用调试.dcus"
- 使用vscode调试时,GDB意外退出
- 即使使用调试编译标志,表达式也是"optimized out"
- 调试 CUDA MMU 故障
- 小字符串优化(调试与发布模式)
- 调试和自由执行中的信号处理
- 调试编译的服务器在数据库打开时崩溃
- Visual Studio 调试优化如何工作?
- 如何配置Visual Studio Code以使用cygwin,cmake和gcc进行调试
- 从 exe 文件 (Visual Studio ) 启动时调试断言失败
- 如何在大型c++项目的可视化代码中设置调试
- Qt 调试显示行号
- 如何将可变参数模板转换为多个单个模板?(C++竞争编程调试模板)