两个，也许是微不足道的问题：
真。我花了最后三天实现比std :: sort更快的东西，只是为了做到这一点。它应该是一个introsort，我怀疑它使用单个pivot版本quicksort里面。史诗失败。我的速度至少慢了两倍。
在我的痛苦中，我甚至复制粘贴其他 - 顶级 - 程序员代码。徒劳无功。 我也对我的其他算法进行了基准测试...我的二进制搜索，以及upper_bound，lower_bound版本都被剥离了，实际上并没有用更少的指令。不过，它们的速度只有两倍。
我问，为什么，为什么，为什么？这引出了我的下一个问题......
当然，我想看看他们的消息来源！是否有可能编写比这些更有效的代码，或者我是否处于抽象级别与我的“简单”main.cpp，我无法达到STL库使用的优化？
我的意思是举例......让我们看看地图......这是简单的联想容器。文档说它是用红黑树实现的。现在......尝试实现我自己的红黑树是值得的，或者他们带走了这个快乐:-)远离我，我应该把我手上的每一个数据都扔到地图容器中？
我希望这确实有意义。 如果没有，请原谅我。
答案 0 :(得分：9)
简短的回答是“如果能够编写更快的代码来执行相同的操作，那么标准库就已经完成了它。”
标准库是由聪明人设计的，它成为C ++的一部分的原因是其他聪明的人认为它是聪明的。从那时起，15年过去了，其他聪明的人试图采用这些规范并编写绝对最有效的代码来实现它们。
这是你想要与之竞争的很多聪明。 ;）
因此STL中没有魔法，他们不会作弊，也不会使用无法使用的技巧。它只是经过精心设计，以最大限度地提高性能。
关于C ++的事情是，它不是一种快速的语言。如果你不小心，很容易引入各种低效：虚函数调用，缓存未命中，过多的内存分配，不必要的对象复制，所有这些都会削弱C ++代码的性能，如果你不小心的话。
小心，您可以编写与STL一样高效的代码。 特殊。但总的来说，你要获得更快的代码的唯一方法就是改变要求。标准库必须是通用的，以便在所有用例中尽可能地工作。如果您的要求更具体，有时可以编写有利于这些特定情况的专用代码。但是，在其他情况下，权衡是代码要么不起作用，要么效率低下。
最后一点是，STL之所以如此聪明，以及为什么它被采用到标准中的关键部分是它几乎是零开销。许多语言的标准库“足够快”，但不如手动代码快。他们有一个排序算法，但它并不像你自己就地编写它那么快。它可能会在常见的“对象”基类中使用一些强制转换，也可能在值类型上使用装箱。 STL的设计使得几乎所有东西都可以被编译器内联，产生的代码相当于你自己手动编写的代码。它使用模板专门针对您正在使用的类型，因此转换为容器或算法所理解的类型没有任何开销。
这就是为什么很难与之竞争的原因。这是一个非常有效的图书馆，它必须是。根据普通C或C ++程序员的心态，特别是10 - 15年前，没有人会使用std::vector，如果它比原始数组慢5％。没有人会使用迭代器和std算法，如果它们没有自己编写循环那么快。
因此，STL开创了许多聪明的C ++技巧，以便与手动C代码一样高效。
答案 1 :(得分：3)
它们可能在很大程度上得到优化。此类实现考虑了内存页面错误，缓存未命中等。
获取这些实现的来源取决于它们随附的编译器。我想大多数编译器（甚至微软）都会允许你看到它们。
我认为最重要的事情是要编译的体系结构以及运行程序的操作系统（如果有的话）。了解这些内容可以让您精确定位硬件。
还有无数的优化技术。 This是一个很好的总结。此外，全球优化是整个科学，因此肯定有许多东西需要学习。
此网站上也有There are some clever things。 Sok sikert！
答案 2 :(得分：2)
查看代码的反汇编版本与其代码并进行比较可能会让您了解为什么它们比您的速度更快。
为了制作更快的版本，从头开始重新实现标准库功能似乎是一件愚蠢的事。尝试修改他们的版本以实现目标会更好，尽管那时你真的需要了解底层平台才能判断你所做的变化的价值。
我猜你会发布你的排序例程，它会在几分钟内被拆散，你会理解为什么你的版本比标准库版本慢得多。
答案 3 :(得分：2)
大多数IDE都有命令使用编译器的搜索路径打开命名头文件。我经常使用它，并倾向于保持algorithm的代码打开。
对我来说，您正在寻找的代码在
中/usr/include/c++/4.2.1/bits/stl_algo.h
/usr/include/c++/4.2.1/bits/stl_tree.h
请注意，很多人已经完成了关于排序和树木平衡的论文（我认为这些领域已被选中，我不会尝试在那里进行研究），其中许多可能比你更有决心GCC的标准库更快。
也就是说，总是有可能利用特定于代码的模式（某些子范围已经排序，经常使用特定的小序列大小等）。
答案 4 :(得分：1)
两个答案，可能一般适用：
您可能无法实现更高效的算法版本，许多其他聪明人已经花费了更多时间进行优化。凭借时间和测试，STD算法将会非常好。
对于相同的算法，优化是对所有当前硬件和配置变化“非常困难”的事情。举一个例子，特定平台上算法性能的主要因素可能是其最常用的例程可以存储在哪个级别的缓存中，这通常不是手工优化的。因此，与您可以编写的任何特定代码相比，编译器通常更多地是实际算法性能的一个因素。
但是，如果你真的认真对待优化，那就进入大会并进行比较吧。不过，我的建议是专注于其他事情，除非你的工作是优化你的实现或其他什么。只是我的2c。