我在Windows下的性能关键C ++代码中使用了很多STL。获得一些额外性能的一种可能的“廉价”方式是更换为更快的STL库。
根据这个post STLport速度更快,占用的内存更少,但是已经有几年了。
最近有人做过这个改变,你的结果是什么?
答案 0 :(得分:15)
我没有将STLPort的性能与MSCVC进行比较,但如果存在显着的差异,我会感到惊讶。 (当然,在发布模式下 - 调试版本可能会有很大差异。)不幸的是,您提供的链接 - 以及我见过的任何其他比较 - 对于细节来说太过有用了。
在考虑更改标准库提供程序之前,我建议您对代码进行大量分析,以确定瓶颈所在。这是标准建议;在尝试任何性能改进之前始终进行配置文件!
即使分析确实揭示了标准库容器或算法中的性能问题,我建议您先分析如何使用它们。算法改进和适当的容器选择,特别是考虑到Big-O成本,更多可能会带来更高的性能回报。
答案 1 :(得分:9)
在进行切换之前,请务必在关闭checked iterators的情况下测试MS(实际上是Dinkumware)库。出于一些奇怪的原因,即使在发布版本中它们也默认打开,这在性能方面有很大的不同。
答案 2 :(得分:6)
我们最近做了相反的任务。我们的应用程序是一个跨平台的C ++服务器程序,它构建在Windows上的VS 2008(x86)和HP-UX ia64和Linux上的gcc 4.3。在每个平台上,我们使用STLport 5.1.7作为STL库和Boost 1.38。
为了比较前一段时间的性能,我们还在没有STLport的情况下构建了应用程序,之后我们测量了性能。
在Windows之后,性能略有提升。因此,我们选择停止在VS 2008中使用STLport并使用默认的VS 2008 STL库。
在HP-UX ia64上,性能下降了20%。 Caliper(HP-UX分析器)显示字符串分配花费更多时间。在默认gcc STL库中的字符串赋值内部,调用了pthread_mutex_unock。据我所知,使用pthread_mutex_lock / pthread_mutex_unlock,因为默认的gcc的STL库使用COW字符串。在我们的应用程序中,我们执行大量字符串分配,并且由于COW字符串,我们的性能会变差。所以我们仍然在使用gcc的HP-UX上使用STLPort。
答案 3 :(得分:5)
在我开展的一个项目中,使用了stl,切换到STLport导致在微软STL实现的一半时间内完成工作。这不是证明,但我认为这是表现的良好迹象。我相信这部分归功于STLport先进的内存管理系统。
我确实记得在进行此更改时收到一些警告,但没有什么是无法快速解决的。作为一个缺点,我要补充一点,使用Visual Studio的调试器调试STLport不如使用Microsoft的STL(更新:似乎有一种方法可以向调试器解释如何处理STLport容器,感谢Jalf!)。
最新版本可以追溯到2008年10月,因此仍然有人在努力。请参阅here下载。
答案 4 :(得分:5)
我在一年前做了完全相反的事情,这就是原因:
答案 5 :(得分:3)
如果您使用STLPort,您将进入一个世界,您使用的每个基于STL的第三方库都必须使用STLPort重新编译,以避免出现问题......
STLPort确实有不同的内存策略,但如果这是你的瓶颈,那么你的性能增益路径就是改变分配器(例如切换到Hoard),而不是改变STL。
答案 6 :(得分:0)
我还没有尝试过,但据我所知,微软的STL实施没有重大变化。 (VS2008编译器在2005年也没有大的新优化)因此,如果STLPort更快,那么情况可能仍然如此。
但这只是猜测。 :) 如果你试一试,一定要报告结果。
答案 7 :(得分:-2)
stlport的一个好处是它是开源的。