使用大型库本质上会使代码变慢吗？

Question

我有一种心理抽搐，这让我不愿意使用大型库（例如 GLib 或 < a href="http://www.boost.org/" rel="noreferrer">Boost）在较低级语言（如 C 和 C++）中。在我心里，我认为：

嗯，这个图书馆有数千个 投入了工时，并且已经 由懂得更多的人创建 关于语言的知识比我以往任何时候都多。 他们的作者和粉丝说 图书馆快速可靠， 而且功能看起来确实 有用，它肯定会阻止我 来自（糟糕的）重新发明轮子。

但该死的，我永远不会使用 该库中的每个函数。它是 太大了，可能会变得臃肿 历年;这是另一个球 并链接我的程序需要拖动。

Torvalds 咆哮（尽管存在争议）也不能让我安心。

我的想法有任何依据吗，还是我只是不合理和/或无知？即使我只使用大型库的一两个功能，通过链接到该库我是否会产生运行时性能开销？

我确信这也取决于特定的库是什么，但我通常有兴趣了解大型库是否会在技术层面上固有地引入低效率。

当我没有技术知识来知道我是否正确时，我厌倦了对此的痴迷、抱怨和担忧。

请让我脱离痛苦！

Answer 1

即使我只使用大型库的一两个功能，通过链接到该库我是否会产生运行时性能开销？

一般来说，没有。

如果相关库没有大量与位置无关的代码，那么当动态链接器在请求时对库执行重定位时，将会产生启动成本。通常，这是程序启动的一部分。除此之外，不会对运行时性能产生影响。

链接器还擅长在构建时从静态链接库中删除“死代码”，因此您使用的任何静态库都将具有最小的大小开销。性能甚至不参与其中。

坦率地说，你担心的是错误的事情。

Answer 2

我无法对 GLib 发表评论，但请记住，Boost 中的许多代码都是头文件，并且考虑到用户只需为他们使用的内容付费的 C++ 原则，这些库非常高效。有几个库需要您链接它们（正则表达式、文件系统），但它们是单独的库。使用 Boost，您不必链接到大型整体库，而只能链接到您使用的较小组件。

当然，另一个问题是——替代方案是什么？您想在需要时自己实现 Boost 中的功能吗？鉴于许多非常有能力的人已经研究过这段代码，并确保它可以在多种编译器上运行并且仍然高效，这可能并不是一项简单的任务。另外，至少在某种程度上，你正在重新发明轮子。恕我直言，你可以更高效地度过这段时间。

Answer 3

Boost 不是一个大库。

它是许多小型图书馆的集合。它们中的大多数都非常小，包含在一个或两个标头中。使用 boost::noncopyable 不会将 boost::regex 或 boost::thread 拖到您的代码中。他们是不同的图书馆。它们只是作为同一图书馆馆藏的一部分分发。但您只需为您使用的部分付费。

但一般来说，因为大型库确实存在，即使 Boost 不是其中之一：

我的想法有任何依据吗，还是我只是不合理和/或无知？即使我只使用大型库的一两个功能，通过链接到该库我是否会产生运行时性能开销？

没有任何依据，或多或少。
你可以自己测试一下。

编写一个小型 C++ 程序并编译它。现在向其中添加一个新函数，该函数从未被调用，但已定义。再次编译程序。假设启用了优化，它会被链接器删除，因为它未被使用。因此，包含额外的未使用代码的成本为零。

当然也有例外。如果代码实例化任何全局对象，则这些对象可能不会被删除（这就是包含 iostream 标头会增加可执行文件大小的原因），但一般来说，您可以包含尽可能多的标头并链接到尽可能多的库只要您不使用任何添加的代码，它就不会影响程序的大小、性能或内存使用情况*。

另一个例外是，如果动态链接到 .dll 或 .so，则必须分发整个库，因此不能删除未使用的代码。但是静态编译到可执行文件中的库（作为静态库（.lib 或 .a）或仅作为包含的头文件）通常可以由链接器修剪，删除未使用的符号。

Answer 4

从代码性能角度来看，大型库将

• 占用更多内存，如果它有运行时二进制文件（boost的大部分部分不需要运行时二进制文件，它们是“仅标头”）。虽然操作系统只会将库中实际使用的部分加载到 RAM，但它仍然可以加载超出您需要的内容，因为加载内容的粒度等于页面大小（但在我的系统上仅 4 Kb）。
• 如果再次需要运行时二进制文件，

  需要更多时间通过动态链接器加载。每次加载程序时，动态链接器都必须将您需要外部库包含的每个函数与其在内存中的实际地址相匹配。这需要一些时间，但只是一点点（但是，对于加载许多程序的规模来说，这很重要，例如桌面环境的启动，但你在那里别无选择）。

  是的，每次调用共享（动态链接）库的外部函数时，在运行时都需要一次额外的跳转和几次指针调整

是的，从开发人员的性能角度来看， ：

• 添加外部依赖项。你将依赖别人。即使该库是免费软件，您也需要额外的费用来修改它。一些非常低级程序（我指的是操作系统内核）的开发人员讨厌依赖任何人——这就是他们的职业福利。因此，咆哮。

  但是，这可以被视为一种好处。如果其他人习惯了boost，他们会在您的程序中找到熟悉的概念和术语，并且会更有效地理解和修改它。

• 较大的库通常包含特定于库的概念，需要时间来理解。考虑 Qt。它包含信号和槽以及与moc相关的基础设施。与整个 Qt 的大小相比，学习它们只需要一小部分时间。但如果您使用如此大的库的一小部分，这可能是一个问题。

Answer 5

过多的代码并不会神奇地使处理器运行速度变慢。它所做的只是坐在那里，占用一点内存。

如果您进行静态链接并且您的链接器完全合理，那么它将仅包含您实际使用的函数。

Answer 6

我喜欢用平台技术来形容框架、库集和某些类型的开发工具。平台技术的成本超出了代码大小和性能的影响。

1. 如果您的项目本身旨在用作库或框架，那么您最终可能会将您的平台技术选择推送给使用您的库的开发人员。

2. 如果您以源代码形式分发项目，您最终可能会将平台技术选择推送给最终用户。

   如果您以源代码形式分发项目，您最终

3. 如果您不静态链接所有选择的框架和库，最终可能会给最终用户带来库版本控制问题的负担。

   如果您不静态链接所有

4. 编译时间会影响开发人员的工作效率。增量链接、预编译标头、适当的标头依赖项管理等可以帮助管理编译时间，但不能消除与某些平台技术引入的大量内联代码相关的编译器性能问题。

5. 对于作为源代码分发的项目，编译时间会影响项目的最终用户。

   对于作为源

6. 许多平台技术都有自己的开发环境要求。这些要求可能会累积起来，使得项目的新开发人员很难复制允许编译和调试所需的环境。

7. 使用一些平台技术实际上为该项目创建了一种新的编程语言。这使得新开发人员更难做出贡献。

所有项目都具有平台技术依赖性，但对于许多项目来说，将这些依赖性保持在最低限度确实有好处。

Answer 7

如果这些库是动态链接的，则加载这些库时可能会产生少量开销。这通常只是程序运行时间的一小部分。

然而，一旦所有内容都加载完毕，就不会产生任何开销。

如果您不想使用 全部 的 boost，那就不要使用。它是模块化的，因此您可以使用您想要的部分而忽略其余部分。

Answer 8

更大并不意味着更慢。与其他一些答案相反，完全存储在标头中的库和存储在目标文件中的库之间也没有固有的区别。

仅头文件库可以具有间接优势。大多数基于模板的库必须只有标头（或者很多代码最终都在标头中），并且模板确实提供了很多优化的机会。然而，将代码放入典型的目标文件库中并将其全部移至标头中通常不会产生许多良好的效果（并且可能导致代码膨胀）。

特定库的真正答案通常取决于其整体结构。人们很容易认为“Boost”是一个巨大的东西。事实上，它是一个巨大的库集合，其中大多数库都非常小。作为一个整体，你不能对 Boost 说太多（有意义的），因为各个库是由不同的人编写的，具有不同的技术、目标等。其中一些库（例如 Format、Assign）确实比几乎任何库都慢你很可能会自己做。其他的（例如 Pool）提供了您可以自己做的事情，但可能不会，以获得至少较小的速度改进。少数人（例如 uBlas）使用重型模板魔法来运行得比我们中的一小部分人希望自己达到的速度更快。

当然，有相当多的库确实是单独的大型库。在相当多的情况下，这些确实比您自己编写的要慢。特别是，其中许多（大多数？）试图比您自己编写的几乎任何内容都更加笼统。虽然这并不一定会导致代码变慢，但在这个方向上肯定存在着强烈的趋势。与许多其他代码一样，当您以商业方式开发库时，客户往往对功能更感兴趣，而不是诸如速度大小之类的东西。

有些库还投入了大量的空间、代码（通常至少是一些时间）来解决您可能根本不关心的问题。举个例子，几年前我使用了一个图像处理库。它对 200 多种图像格式的支持听起来确实令人印象深刻（在某种程度上确实如此），但我很确定我从未用它来处理超过十几种格式（而且我可能只支持其中一半就可以了）许多）。 OTOH，尽管如此，它仍然相当快。支持较少的市场可能会限制其市场，以至于代码实际上会更慢（例如，它处理 JPEG 的速度比 IJG 快）。

Answer 9

正如其他人所说，添加动态库时会产生一些开销。首次加载库时，必须执行重定位，尽管如果库编译正确，这应该是很小的成本。由于需要搜索的库的数量增加，因此查找单个符号的成本也增加。

添加另一个动态库的内存成本很大程度上取决于您实际使用的内存量。在执行某页代码之前，不会从磁盘加载该代码页。然而，库文件中内置的其他数据，如头、符号表和哈希表也会被加载，这些数据通常与库的大小成正比。

glibc 的主要贡献者 Ulrich Drepper 有一个 很棒的文档，其中描述了进程和动态库的开销。

Answer 10

取决于链接器如何工作。有些链接器是惰性的，会包含库中的所有代码。更高效的链接器只会从库中提取所需的代码。我对这两种类型都有过经验。

较小的库对任何类型的链接器都不会那么担心。对于小型库来说，最糟糕的情况是少量未使用的代码。许多小型库可能会增加构建时间。权衡是构建时间与代码空间。

对链接器的一个有趣的测试是经典的 Hello World 程序：

#include <stdio>
#include <stdlib>
int main(void)
{
  printf("Hello World\n");
  return EXIT_SUCCESS;
}

由于 可能 的所有格式，printf 函数有很多依赖项需要。懒惰但快速的链接器可能包含一个“标准库”来解析所有符号。更高效的库将仅包含 printf 及其依赖项。这使得链接器变慢。

上面的程序可以与使用 puts 的程序进行比较：

#include <stdio>
#include <stdlib>
int main(void)
{
  puts("Hello World\n");
  return EXIT_SUCCESS;
}

通常，puts 版本应该小于 printf 版本，因为 puts 没有格式化需求，因此依赖性更少。惰性链接器将生成与 printf 程序相同的代码大小。

总之，库大小的决定更多地依赖于链接器。具体来说，是链接器的效率。当有疑问时，许多小型库将减少对链接器效率的依赖，但会使构建过程更加复杂和缓慢。

Answer 11

1. 一般而言，与性能问题相关的事情不是要娱乐它们，因为这样做就是猜测它们是一个问题，因为如果您不知道它们是，你就在猜测，而猜测是“过早优化”背后的核心概念。处理性能问题的关键在于，当您遇到性能问题时，而不是之前，诊断它们。这些问题几乎从来都不是你能猜到的。 。

2. 如果您这样做在相当多的时间里，您将逐渐认识到往往会导致性能问题的设计方法，无论是在您的代码中还是在库中。 （库肯定会存在性能问题。）当您了解这一点并将其应用到项目中时，在某种意义上您就过早地进行了优化，但无论如何它已经达到了避免问题的预期效果。 我可以总结一下您可能会学到的内容，那就是太多的抽象层和过度的类层次结构（尤其是那些充满通知式更新的类层次结构）通常是导致性能问题的原因。

同时，我也同意您对第三方库等的谨慎态度。我曾多次参与过一些项目，其中一些第三方软件包被“利用”以实现“协同”，然后供应商要么灰飞烟灭，要么放弃该产品，或者因为微软改变了操作系统中的内容而使其过时。然后，我们严重依赖第 3 方软件包的产品开始无法运行，需要我们投入大量资金，而原来的程序员早已离开。

Answer 12

“另一个球和链”。真的吗？

或者它是一个稳定、可靠的平台，可以首先支持您的应用程序？

考虑到有些人可能喜欢“太大且……臃肿”的库，因为他们将其用于其他项目并且真正信任它。

事实上，他们可能会拒绝干扰您的软件，特别是因为您避免使用明显的“太大且……臃肿”的库。

Answer 13

从技术上讲，答案是肯定的。然而，这些低效率实际上非常很少重要。我在这里假设使用 C、C++ 或 D 等静态编译语言。

当可执行文件加载到现代操作系统的内存中时，地址空间只是映射到它。这意味着，无论可执行文件有多大，如果有整个页面大小的代码块未使用，它们将永远不会触及物理内存。不过，您会浪费地址空间，有时这在 32 位系统上可能会有点影响。

当您链接到库时，好的链接器通常会丢弃您不使用的多余内容，尽管特别是在模板实例化的情况下，这种情况并不总是发生。因此，您的二进制文件可能比严格需要的要大一些。

如果您不经常使用的代码与确实使用的代码交错，则最终可能会浪费 CPU 缓存中的空间。然而，由于缓存行很小（通常为 64 字节），因此这种情况很少会发生到实际重要的程度。

Answer 14

问问自己你的目标是什么。它是当今的中端工作站吗？没问题。如果是较旧的硬件，甚至是有限的嵌入式系统，那么它可能是。

正如之前的发帖者所说，仅在那里放置代码不会对性能造成太大影响（它可能会减少缓存的局部性并增加加载时间）。

Answer 15

fwiw，我在 Microsoft Windows 上工作，当我们构建 Windows 时；针对 SIZE 编译的构建比针对 SPEED 编译的构建更快，因为页面错误命中次数更少。

Answer 16

FFTW 和 ATLAS 是两个相当大的库。奇怪的是，它们在世界上最快的软件和为在超级计算机上运行而优化的应用程序中发挥着重要作用。不，使用大型库不会使您的代码变慢，尤其是当您自己实现 FFT 或 BLAS 例程时。

Answer 17

你的担心是有道理的，尤其是在提升的时候。这并不是因为写这些文章的人不称职，而是因为两个问题。

1. 模板本质上只是臃肿的代码。这在 10 年前并不重要，但如今 CPU 的速度比内存访问快得多，并且这种趋势仍在继续。我几乎想说模板是一个过时的功能。

对于通常有些实用的用户代码来说，这并不是那么糟糕，但在许多库中，所有内容都是根据其他模板或多个项目上的模板来定义的（意味着指数模板代码爆炸）。

只需添加 iostream 即可为您的代码增加大约 3 mb (！！！)。现在添加一些 boost 废话，如果您简单地声明几个特别奇怪的数据结构，您就会有 30 mb 的代码。

更糟糕的是，您甚至无法轻松地对此进行分析。我可以告诉你我编写的代码和模板库中的代码之间的区别是巨大的，但对于更天真的方法，你可能会认为你在简单的测试中做得更糟，但代码膨胀的成本将在大型现实世界中发挥其作用应用程序。

2. 复杂。当你查看 Boost 中的内容时，它们都会使你的代码在很大程度上变得复杂。像智能指针、函子、各种复杂的东西。现在，我不会说使用这些东西从来都不是一个好主意，但几乎所有这些东西都有某种巨大的成本。特别是如果你不明白，我的意思是，它到底在做什么。

但人们对它赞不绝口，并假装它与“设计”有关，这样人们就会觉得这是你做所有事情都应该采用的方式，而不仅仅是一些应该很少使用的极其专业的工具。如果有的话。