【问题标题】:What is the STL implementation with the lowest memory footprint?内存占用最少的 STL 实现是什么?
【发布时间】:2010-09-12 09:58:42
【问题描述】:

我正在开发一个大量使用 STL 的超大规模计算库。该库正在使用 MSVC2003 构建,并且正在使用其 STL 实现。 我正在寻找一种替代的 STL 实现,它可以帮助库降低其内存需求并提高其性能。

目前无法切换到更新版本的 MSVC。

如果可能的话,我希望得到一些关于不基于基准的实际使用情况的反馈。

编辑:为了更清楚一点,例如一些 STL 实现(如 STLSoft)正在为字符串连接提出特定的优化;这些可能听起来影响很小,但它们可以带来很大的改进。 STLPort 是另一个很好的例子,他们清楚地说明了他们的目标:拥有最快的 STL 实现,有 stdlib++ 等......所有这些都可以是很好的候选者,但我没有时间测试它们,我需要一些社区帮助关于那个。

【问题讨论】:

  • 也许你最好将你的问题改写为“什么是.. 内存消耗最低”,或者添加主观标签。
  • 我想知道 LLVM 项目中的新 libc++ 与其他实现相比如何。据说它依赖于一些 C++11 特性以获得更好的性能。有人有这方面的经验吗?

标签: c++ optimization stl


【解决方案1】:

STLPort。尚未测量内存使用差异,但它肯定更快(是的,真实世界的使用)。

【讨论】:

  • 值得注意的是,即使是视频游戏开发人员也使用 STLPort。见:遗物。
  • @Hooked:只能列出一个使用它的工作室吗?这是有史以来最糟糕的抽样基础。 ;)
  • 哦,如果我想用大量数据点让你眼花缭乱,我会更加努力。 :D
【解决方案2】:

我质疑您的基本前提,即您不能切换到更新版本的 MSVC。

我认为下载新的 STL 不会“免费”降低内存并提高性能。或者至少,如果您这样做了,您可能需要进行尽可能多的代码修复,就像您要更新到最新的 MSVC 一样。

从长远来看,毫无疑问您想更新...现在就去做,您可能会很幸运并免费获得一些内存和性能。

按照您所说的您正在寻找的内容,我能想到的唯一建议是尝试英特尔编译器,我有好(性能!)和坏(古怪,有时!)的经验。

除此之外,找到您自己的内存和性能问题,并编写自定义容器和算法。 STL 很棒,但它并不是解决所有问题的灵丹妙药。领域知识是您最好的盟友。

【讨论】:

  • 您的回答没有任何帮助,因为您显然提出了一些目前不能考虑而且显然不会考虑的事情。
  • 许多领域专家已经知道,STL 实现具有不同的性能和内存配置文件。基于这一事实,我觉得找到最适合其他人的方法并在我自己的应用程序中试用它们似乎是公平的。
  • 我的意思是“域”,你的实际问题空间。 IE,我使用医疗保健软件,所以我使用自定义容器和算法,这些容器和算法特定于我的医疗保健软件中常见的访问模式。我同意 yrp 的观点,即 STLPort 值得一试。
【解决方案3】:

您是否考虑过编写自己的内存分配器?如果你只是不喜欢内存分配策略,你并不总是需要切换整个 STL。所有容器都接受替换分配器。

【讨论】:

    【解决方案4】:

    您是否分析过您的代码并考虑对那些有问题的区域进行微调?我认为这会比您考虑的要痛苦得多。

    【讨论】:

      【解决方案5】:

      这在很大程度上取决于您所谈论的容器以及您如何使用它。 向量通常具有最小的占用空间,除非您添加的元素超出了当前向量的容量。那时它会分配 1.5 x 当前向量容量,移动元素(或者在最坏的情况下制作一个新的副本,同时分配内存),完成后,删除旧的向量内部,如果你知道如何它将保留许多元素,使用保留的矢量是您最好的选择。

      第二小的是列表。它的优点是它不会制作自己的临时副本。在那之后,你最好的赌注可能已经成立。一些实现现在有 slist,它更小。在这些情况下, tt 很容易制作一个将内存打包成页面的分配器。 远离像 unordered_* 这样的记忆猪

      在 MSVC 上确保 #define _SECURE_SCL=0 这会减少用于安全编程检查(如缓冲区溢出等)的大量开销

      到目前为止,内存效率最高的容器是 boost/intrusive 这些容器占用空间极小,因为它们使用所包含事物的内存。因此,对于链表或 rb 树节点来说,为了一小块内存进入堆,节点指针是对象本身的一部分。那么“容器”只是一个原始的一组几个指针来创建一个根节点。我已经多次使用它来消除占用空间和分配开销。

      【讨论】:

        【解决方案6】:

        大多数 STL 实现,包括 MSVC2003 之一,都是实现良好的通用库。因此,您不会看到从一种实现到另一种实现的显着性能提升。

        但是,有时您可以为您编写比 STL 更快的算法(或容器),因为您知道 STL 编写者没有新的数据(因为他们正在编写通用容器和算法)。

        总之,如果您想提高应用程序的性能,最好尝试创建专门适合您的数据的容器,而不是寻找性能更高的 STL。

        【讨论】:

          【解决方案7】:

          如果性能对您的应用程序如此重要,并且 STL 交织在其中,是否有可能找到一个开源实现(如 STL-Port,如上所述)并为自己分叉,根据需要进行性能改进?

          一方面,我可以看到这变成了一个滑坡,您对 STL 库的分支进行非标准修改,从而产生问题。但是,性能对您的应用程序的重要性可能超过发生这种情况的风险。

          【讨论】:

          • 性能不太可能是关键,因为他们不能升级的声明。如果它真的很关键,它会胜过不升级的说法。
          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2010-09-29
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多