从 Microsoft STL 切换到 STLport
我在 Windows 下的性能关键的 C++ 代码中使用了大量的 STL。 获得额外性能的一种可能的“廉价”方法是更改为更快的 STL 库。
根据这个 帖子 STLport 更快并且使用内存较少，但已经有几年了。
最近有人进行过此更改吗？结果如何？
I'm using quite much STL in performance critical C++ code under windows. One possible "cheap" way to get some extra performance would be to change to a faster STL library.
According to this post STLport is faster and uses less memory, however it's a few years old.
Has anyone made this change recently and what were your results?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我还没有比较 STLPort 和 MSCVC 的性能，但如果存在显着差异，我会感到惊讶。 （当然，在发布模式下 - 调试版本可能会完全不同。）不幸的是，您提供的链接 - 以及我见过的任何其他比较 - 细节太少而无用。
在考虑更改标准库提供程序之前，我建议您仔细分析代码以确定瓶颈所在。 这是标准建议； 在尝试任何性能改进之前始终进行分析！
即使分析确实揭示了标准库容器或算法中的性能问题，我建议您首先分析如何使用它们。 算法改进和适当的容器选择，尤其是考虑到 Big-O 成本，更有可能带来更大的性能回报。
I haven't compared the performance of STLPort to MSCVC but I'd be surprised if there were a significant difference. (In release mode of course - debug builds are likely to be quite different.) Unfortunately the link you provided - and any other comparison I've seen - is too light on details to be useful.
Before even considering changing standard library providers I recommend you heavily profile your code to determine where the bottlenecks are. This is standard advice; always profile before attempting any performance improvements!
Even if profiling does reveal performance issues in standard library containers or algorithms I'd suggest you first analyse how you're using them. Algorithmic improvements and appropriate container selection, especially considering Big-O costs, are far more likely to bring greater returns in performance.
在进行切换之前，请务必使用 检查的迭代器测试 MS（实际上是 Dinkumware）库关闭。 由于一些奇怪的原因，即使在发布版本中它们也默认打开，这在性能方面产生了很大的差异。
Before making the switch, be sure to test the MS (in fact, Dinkumware) library with checked iterators turned off. For some weird reason, they are turned on by default even in release builds and that makes a big difference when it comes to performance.
我们最近做了相反的任务。 我们的应用程序是一个跨平台的 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。 据我所知，由于默认的 gcc 的 STL 库使用 COW 字符串，所以使用了 pthread_mutex_lock/pthread_mutex_unlock 。 在我们的应用程序中，我们进行了大量的字符串分配，由于使用了 COW 字符串，我们的性能变得更差。 所以我们仍然在 HP-UX 上使用 STLPort 和 gcc。
We have done the opposite task recently. Our application is a cross-platform C++ server program and it is built on Windows with VS 2008 (x86) and on HP-UX ia64 and Linux with gcc 4.3 . On every platform we used the STLport 5.1.7 as an STL library and Boost 1.38.
In order to compare performance some time ago we also built our application without STLport and after that we measured performance.
After that on Windows the performance became slightly better. So we chose to stop using the STLport with VS 2008 and to use the default VS 2008 STL library.
On HP-UX ia64 there was 20% decrease in performance. Caliper (the HP-UX profiler) showed that string assignments took more time. And inside of string assignment in the default gcc STL library there were calls to pthread_mutex_unock. As far as I know pthread_mutex_lock/pthread_mutex_unlock are used since the default gcc's STL library uses COW-strings. In our application we do lots of string assignments and as a result of the COW strings we get worse performance. So we still use STLPort on HP-UX with gcc.
在我从事的一个项目中，大量使用了 stl，切换到 STLport 后，完成工作的时间是使用 Microsoft STL 实现的一半。 这不是证据，但我想这是表现的良好标志。 我相信这部分归功于 STLport 先进的内存管理系统。
我确实记得在进行此更改时收到了一些警告，但没有什么不能快速解决的。 作为一个缺点，我要补充一点，使用 Visual Studio 的调试器进行 STLport 调试不如使用 Microsoft 的 STL 容易（更新：似乎有一种方法可以向调试器解释如何处理 STLport 容器，谢谢 Jalf！）。
最新版本可以追溯到 2008 年 10 月，因此仍然有人在开发它。 请参阅此处下载它。
In a project i worked on that makes quite heavy use of stl, switching to STLport resulted in getting things done in half the time it took with Microsoft's STL implementation. It's no proof, but it's a good sign of performance, i guess. I believe it's partly due to STLport's advanced memory management system.
I do remember getting some warnings when making this change, but nothing that couldn't be worked around fast. As a drawback, I'd add that debugging with STLport is less easy with Visual Studio's debugger than with Microsoft's STL (Update : it seems there is a way to explain to the debugger how to handle STLport containers, thanks Jalf !).
The latest version goes back to October 2008 so there are still people working on it. See here for downloading it.
一年前我做了完全相反的事情，原因如下：
I've done the exact opposite a year ago and here is why:
如果您使用 STLPort，您将进入一个世界，您使用的每个基于 STL 的第三方库都必须使用 STLPort 重新编译以避免出现问题...
STLPort 确实有不同的内存策略，但如果这是您的瓶颈，那么你的性能增益路径是改变分配器（例如切换到 Hoard），而不是改变 STL。
If you use the STLPort you will enter a world where every STL-based third party library you use will have to be recompiled with STLPort as well to avoid problems...
STLPort does have a different memory strategy, but if this is your bottleneck then your performance gain path is changing the allocator (switching to Hoard for example), not changing the STL.
我没有尝试过，但据我所知，微软的STL实现并没有发生重大变化。 （与 2005 年相比，VS2008 编译器也没有重大的新优化）因此，如果当时 STLPort 更快，情况可能仍然如此。
但这只是猜测。 :)
如果您尝试一下，请务必报告结果。
I haven't tried it, but as far as I know, there have been no major changes to Microsoft's STL implementation. (There are no huge new optimizations in VS2008 compiler over 2005 either) So if STLPort was faster then, it's probably still the case.
But that's just speculation. :)
Be sure to report back on the results if you try it out.
stlport 的好处之一是它是开源的。
One benefit of stlport is that it's open source.