【问题标题】:Comparing std::vector or std::set in this case for time complexity - More efficent?在这种情况下比较 std::vector 或 std::set 的时间复杂度 - 更有效?
【发布时间】:2014-12-02 23:25:15
【问题描述】:

我目前有一个返回字符串的函数。我需要跟踪这些返回的字符串,如果没有对返回的字符串执行操作,那么我必须对其执行操作。

我的第一个想法是使用向量(即)std::vector。

这是利用向量的机制的样子

1-使用 std::find 检查项是否存在于向量中

std::find(vector.begin(), vector.end(), item)!=vector.end()

2-如果项目不存在,则执行 push_back(摊销常数) 并对其执行操作,否则忽略字符串

我的第二个想法是使用 std::set

1-通过插入功能检查集合中是否存在项目 如果不插入它

 if(set.insert(somestring).second)
    {
      //Item inserted in set and it did not exist

    }

insert in set 的时间复杂度为O(logn)。向量的 push_back 是 Amortized 常数,如果向量未排序(在此未排序)std::find 将为 O(n)。我的假设是否正确,即为了最大效率我应该在这里使用一个集合?有什么我可能会错过的吗?

【问题讨论】:

  • 我是新手,但为什么不使用哈希表、std::map 或 std::unordered_map 来检查它是否存在?无论如何,您都在存储字符串。
  • "如果向量没有排序(在此它不是),它将是 O(logn)" - O(logn) 是多少?
  • 刚刚更新。我的意思是std::find 上的std::vector<std::string> 将 O(n)
  • vector 上的查找是 O(n)。在 set 上的查找是 O(log n)。在 unordered_set 上的查找是 O(1)。我认为我们有一个明显的赢家。
  • @MorphingDragon 是的,但他必须写那个。其他选项,他有免费的。

标签: c++ vector stl set


【解决方案1】:

我曾经在一家银行从事外汇定价系统的工作。我们对性能非常感兴趣。我们曾经对最优算法进行过长时间的讨论……然后有一天,我们用分析工具测量了性能……我们发现实际算法占用了 5% 的处理时间。当系统从消息总线接收和发送消息时,剩下的 95% 用于将字符串转换为双精度型和双精度型到字符串。

我为什么要写这个?只是为了说明在几乎所有情况下,您的容器的选择可能是无关紧要的。您的程序不太可能花费超过一小部分时间来查找地图、集合或向量中的项目。

以最优雅和可维护的方式编写代码,使用易于理解的算法和自然适合设计的容器(用于需要排序的东西的集合和映射,用于一般存储的向量,无序集合和映射,如果顺序并不重要,而且您的数据集很大)。如果您需要对同一数据进行多个有序索引,则可能需要一个用于存储的向量,其中包含用于索引的迭代器/指针集(如数据库)。

然后,当它完成时,如果您的用户对您大喊它太慢(他们不会——他们更关心它是否可靠地工作),请分析代码并测量瓶颈。它们几乎总是在 I/O 中。

如果在极不可能的情况下,您的代码将 90% 的时间用于管理数据集合,那么是时候重新考虑算法了,因为设计可能效率低下 - 或者您正在编写蛋白质折叠模拟器。

如果您确定设计是最优的,那么也许是时候重新考虑容器的类型了。

基本上只有 3 种类型 - 您可以通过反复试验找到最佳解决方案,而花费的时间比争论它所花费的时间更短。

:-)

【讨论】:

  • 即使在视频游戏和实时处理等领域,我们也倾向于将其正确化,然后竭尽全力优化它。
  • ...我敢打赌,与管理八叉树相比,您花费更多的周期将数据通过总线推送到视频卡?
  • 这取决于架构。较新的 SoC 或 APU 不会受到 CPU 和 GPU 共享内存的影响。即使这样,主要的“修复”也是使渲染器成为多线程的,这样它就可以处理在 GPU 上的等待。
  • “QuickSort vs MergeSort”可能是实际分析代码的最佳论据。两者在纸面上具有相同的复杂性,但根据计算机的资源和数据集的大小,行为却大不相同。
猜你喜欢
  • 1970-01-01
  • 2016-05-24
  • 1970-01-01
  • 2012-07-31
  • 2022-10-22
  • 1970-01-01
  • 2011-01-27
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多