|
4
|
| Martin Ba · 技术社区 · 15 年前 |
|
|
1
3
在不知道运行此代码的平台和访问模式的情况下,很难说
例如,如果您有一个非常稀疏的数组,则对
另一方面,您可能有一些稀疏的数组。有点稀疏,我的意思是集合元素的数量远远大于l1或l2。在这种情况下,更多的低级细节开始发挥作用,以及您的实际访问模式。
例如,在某些平台上,可变比特移位的成本非常昂贵。因此,如果您查询的是一组随机的标识符,那么执行此操作的频率越高,则
此时,您可能还想知道稀疏标识符实际上是如何分布的。如果它们是成堆的,您需要知道最佳内存读取大小和每次读取一个字符之间的权衡。这将决定更频繁地访问缓存是否会抵消非本机大小数据中的读取。
如果标识符是分散的,则可以通过使用哈希集获得显著的胜利。(
|
|
|
2
2
您签出了boost::dynamic\u位集了吗? http://www.boost.org/doc/libs/1_36_0/libs/dynamic_bitset/dynamic_bitset.html |
|
|
3
2
假设最大标识符是预先确定的,且不大于1e6(1m)
使用A
|
|
|
4
1
如果按性能来说,你是指最快查找的那个STD::BITSET可能是足够快的,因为它的查找是固定时间的。将所有位设置为零有一个初始开销。矢量<int>的速度可能会非常快,并且设置比特的开销会更大,因为在32位系统中,比特的数量是32倍。 vector<bool>在其实现中与bitset类似,并且具有在需要时可调整大小的优势,尽管通常我会避免vector,如果需要调整大小,请使用boost的动态位集。 STD:SET将是O(log n)在查找和插入/删除中,尽管它是最可扩展的内存使用,如果集合不是特别满,则占用更少。STD::设置在范围内不受限制。 如果数据比较稀疏,有些形式的哈希也是一个选项,通常是O(1)设置和查找,尽管冲突处理可能会有一些开销。 |
|
|
5
0
最快的似乎是使用位掩码。你应该构建一个
这似乎比
|
|
6
0
你可以一直拥有
|
|
Sweepy Dodo · JSON lite的格式化 1 年前 |
|
|
giantjenga · 优化整数向量到二进制向量的转换 1 年前 |
|
Zegarek · Postgresql递归查询未提供预期结果 1 年前 |
|
|
Joe · 为什么这两个查询之间的性能存在如此大的差异? 1 年前 |
|
tic-toc-choc · 在`dplyr中高效使用列表进行过滤` 1 年前 |