最近我看到C和C ++之间存在一些速度差异，有时候说它们中的哪一个在一种情况下或另一种情况下速度更快是不可预测的。
我知道STL自推出以来已经简化了很多，但它是否以速度/内存成本简化了什么？
例如，有多种方法可以使用带指针的结构来定义堆栈/队列/二进制树/图形等。但是，这些实现更加繁琐。另一种完成所有这些操作的方法是使用STL中的矢量，该矢量具有使用模板随意增大和减小的能力。还有许多用于地图，队列等的模板。
我的问题是，您认为哪种实现在时间和内存复杂性方面更有效？为什么？
答案 0 :(得分：2)
C ++标准库已经开发，调整性能，并经过多年调试，通过编译器优化改进，您可以从标准容器中获得非常好的性能。可能最大的性能瓶颈是堆积以获取内存，在某些情况下可以减少，例如reserve的向量。
如果您正在编写C ++，请使用您可用的所有容器和算法，具体取决于您的软件需求。然后，如果您遇到性能问题，可以对代码进行分析（很可能瓶颈仍然不是标准库）。
答案 1 :(得分：0)
这里的关键当然是如果你使用“侵入式”解决方案，也就是说，你在每个节点内存储链表的链接，而不是拥有一个单独的节点结构，该结构包含指向某个其他位置的指针/引用保存数据本身会有一些性能影响[并且可以在两个方向上起作用 - 不一定是侵入式解决方案总是最好的]。
人们弄错的典型情况是，他们比较将某个分配的对象存储在某种容器中，然后将其与存储容器副本的解决方案进行比较。如果该容器是需要通过重新分配来“增长”的容器，那么它将导致性能问题。但这只是“如果要存储的东西的错误选择”或“这种类型的对象存储的错误种类的容器”。
对于大多数情况，实施你如何做某事（例如它是树或矢量）是你获得100倍改进的地方。针对此类存储的特定内容将为您提供5-20％的改进，具体取决于原始代码的优化程度以及优化代码的编写程度。现在，假设它不是游戏中渲染循环的内部细节，或OS内核中的sheduler或内存分配代码的一部分，5％是不值得拥有的，对于绝大多数代码，可能有20％的改进[系统功能的一部分 - 如果你把东西存放在一个容器中，希望你用它做更多的事情而不仅仅是简单存储它并在容器内容上来回运行，对吧？）
在花费任何时间优化代码之前，应该对代码花费时间的地方进行一些体面的分析。然后你可以攻击让它变得更好。第一步是看“这里算法的行为是什么？”当我们可以使用更快的不同方法时，我们是否花费O（2 ^ n）来对事物进行排序？当列表，堆栈或队列可能是更好的选择时，我们是否花时间从大型数组中插入/删除内容？当我们编写较少数量的大块时，我们是否将小块数据写入磁盘？
这些问题将为您提供5,10,100x的改进，使真正与众不同。当然，削减5％的东西值得做。有时候剃须0.5％是值得做的，如果这是让你的游戏以200fps而不是100fps运行的原因，因为它会使你超过帧开关速率的半个百分点。但总的来说，如果它不至少加倍速度，你可能应该把时间花在其他地方。