windows 从微软的 STL 切换到 STLport

Switch from Microsofts STL to STLport

提问by Laserallan

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.

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

According to this postSTLport is faster and uses less memory, however it's a few years old.

根据这篇文章，STLport 速度更快，使用的内存更少，但它已经有几年的历史了。

Has anyone made this change recently and what were your results?

最近有人做过这个改变吗？你的结果是什么？

采纳答案by MattyT

I haven't compared the performance of STLPort to MSCVC but I'd be surprised if there were a significantdifference. (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.

我没有将 STLPort 的性能与 MSCVC 进行比较，但如果存在显着差异，我会感到惊讶。（当然，在发布模式中 - 调试版本可能会大不相同。）不幸的是，您提供的链接 - 以及我所看到的任何其他比较 - 细节太少而无用。

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 morelikely to bring greater returns in performance.

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

回答by Nemanja Trifunovic

Before making the switch, be sure to test the MS (in fact, Dinkumware) library with checked iteratorsturned 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.

在进行切换之前，请务必在关闭检查迭代器的情况下测试 MS（实际上是 Dinkumware）库。出于某种奇怪的原因，即使在发布版本中默认情况下它们也是打开的，这在性能方面有很大的不同。

回答by Nemanja Trifunovic

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.

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

In order to compare performance some time ago we also built our application without STLport and after that we measured performance.

前段时间为了比较性能，我们还构建了没有 STLport 的应用程序，然后我们测量了性能。

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.

之后在 Windows 上的性能变得稍微好一些。所以我们选择停止在 VS 2008 中使用 STLport，而是使用默认的 VS 2008 STL 库。

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.

在 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。

回答by Nikola Smiljani?

I've done the exact opposite a year ago and here is why:

一年前我做了完全相反的事情，原因如下：

• StlPort is updated very rarely (as far as I know only one developer is working on it, you can take a look at their commit history)
• Problems building it whenever you switch to new Visual Studio release. You wait for the new make file or you create it yourself but sometimes you can't build it because of some configuration option that you're using. Then you wait for them to make it build.
• When you submit a bug report you wait forever, so basically no support (maybe if you pay). You usually end up fixing it yourself, if you know how.
• STL in Visual Studio has checked iteratorsand debug iterator supportthat is much better than the one in StlPort. This is where most of the slowdown comes from especially in debug. Checked iterators are enabled in both debug and release and this is not something everybody knows (you have to disable them yourself).
• STL in Visual Studio 2008 SP1 comes with TR1 and you don't have this in StlPort
• STL in Visual Studio 2010 uses rvalue references from C++0x and this is where you get a real performance benefit.

• StlPort 很少更新（据我所知只有一个开发人员在做它，你可以看看他们的提交历史）
• 每当您切换到新的 Visual Studio 版本时，都会出现构建它的问题。您等待新的 make 文件或您自己创建它，但有时由于您使用的某些配置选项而无法构建它。然后你等待他们让它构建。
• 当您提交错误报告时，您将永远等待，因此基本上没有支持（也许如果您付费）。如果您知道如何操作，您通常最终会自己修复它。
• Visual Studio 中的 STL 已检查迭代器和调试迭代器支持，这比 StlPort 中的要好得多。这是大部分减速的来源，尤其是在调试中。在调试和发布中都启用了检查迭代器，这不是每个人都知道的（您必须自己禁用它们）。
• Visual Studio 2008 SP1 中的 STL 带有 TR1，而 StlPort 中没有
• Visual Studio 2010 中的 STL 使用来自 C++0x 的右值引用，这是您获得真正性能优势的地方。

回答by Beno?t

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.

在我参与的一个项目中，大量使用 stl，切换到 STLport 导致完成工作的时间比使用 Microsoft 的 STL 实现所需的时间缩短一半。这不是证据，但我想这是性能的一个好兆头。我相信这部分归功于 STLport 的高级内存管理系统。

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 !).

我确实记得在进行此更改时收到了一些警告，但没有什么不能快速解决的。作为一个缺点，我想补充一点，使用 Visual Studio 的调试器调试 STLport 不如使用 Microsoft 的 STL 容易（更新：似乎有一种方法可以向调试器解释如何处理 STLport 容器，感谢 Jalf！）。

The latest version goes back to October 2008 so there are still people working on it. See herefor downloading it.

最新版本可以追溯到 2008 年 10 月，因此仍有人在研究它。请参阅此处下载。

回答by Edouard A.

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，您将进入一个世界，您使用的每个基于 STL 的第三方库都必须使用 STLPort 重新编译以避免出现问题......

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.

STLPort 确实有不同的内存策略，但如果这是你的瓶颈，那么你的性能提升路径是改变分配器（例如切换到 Hoard），而不是改变 STL。

回答by jalf

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.

我没有尝试过，但据我所知，微软的 STL 实现没有重大变化。（VS2008 编译器中也没有比 2005 年更大的新优化）所以如果 STLPort 更快，那么可能仍然如此。

But that's just speculation. :) Be sure to report back on the results if you try it out.

但这只是猜测。:) 如果您尝试一下，请务必报告结果。

回答by Rodyland

One benefit of stlport is that it's open source.

stlport 的一个好处是它是开源的。