从Microsofts到STLport的切换

Question

我在windows下的性能关键型C++代码中使用了相当多的STL。获得额外性能的一种可能的“廉价”方法是改用更快的STL库。

根据这一点，post STLport速度更快，使用的内存更少，但它只有几年的历史。

最近有没有人做了这样的改变，你的结果是什么？

Answer 1

我没有比较STLPort和摩根士丹利资本国际的表现，但如果有显着的差异，我会感到惊讶。(当然，在发布模式下，调试版本可能会有很大的不同。)不幸的是，你提供的链接-以及我所见过的任何其他比较-在细节上太少了，没有用。

在考虑更改标准库提供程序之前，我建议您仔细分析代码以确定瓶颈所在。这是标准的建议；在尝试任何性能改进之前，一定要先配置文件！

即使分析确实揭示了标准库容器或算法中的性能问题，我也建议您首先分析如何使用它们。算法改进和适当的容器选择，特别是考虑到Big-O成本，更有可能带来更大的性能回报。

Answer 2

在进行切换之前，请确保在关闭checked iterators的情况下测试MS (实际上是Dinkumware)库。由于一些奇怪的原因，它们在默认情况下是打开的，甚至在发布版本中也是如此，这在性能方面有很大的不同。

Answer 3

我们最近做了相反的任务。我们的应用程序是一个跨平台的C++服务器程序，它是在WindowsVS2008 (x86)上构建的，在HP-UX ia64和Linux上构建，使用gcc 4.3。在每个平台上，我们都使用STLport 5.1.7作为STL库，并使用Boost 1.38。

为了比较性能，不久前我们还在没有使用STLport的情况下构建了应用程序，之后我们测量了性能。

在此之后，在Windows上的性能略有改善。因此，我们选择停止在VS2008中使用STLport，而使用默认的VS2008STL库。

在HP-UX ia64上，性能下降了20%。Caliper ( HP-UX分析器)显示字符串分配需要更多时间。在默认的gcc STL库中的字符串赋值中，有对pthread_mutex_unock的调用。据我所知，之所以使用pthread_mutex_lock/pthread_mutex_unlock，是因为默认的gcc的STL库使用的是COW-string。在我们的应用程序中，我们进行了大量的字符串赋值，由于使用了COW字符串，性能变差了。因此，我们仍然在HP-UX上使用STLPort，与gcc一起使用。