为什么不将内容标记为内联？

Question

首先,我不是在寻找一种方法来强制编译器内联每个函数的实现.

要降低误导性答案的级别,请确保您了解inline关键字的实际含义.这里有很好的描述,内联vs静态vs extern.

所以我的问题,为什么不标记每个函数定义inline？即理想情况下,唯一的编译单位是main.cpp.或者可能还有一些用于无法在头文件中定义的函数(pimpl idiom等).

这个奇怪的请求背后的理论是,它将为优化器提供最大的信息.它当然可以内联函数实现,但它也可以进行"跨模块"优化,因为只有一个模块.还有其他优点吗？

有没有人用真正的应用程序尝试过这个？性能是否提高了？减少？!？

标记所有函数定义有哪些缺点inline？

• 编译可能会更慢并且会消耗更多内存.
• 迭代构建被破坏,每次更改后都需要重建整个应用程序.
• 链接时间可能是天文数字

所有这些缺点仅影响开发者.运行时缺点是什么？

Answer 1

你真的是指#include一切吗？这只会给你一个模块,让优化器一次看到整个程序.

实际上,当你使用/GL(整个程序优化)开关时,微软的Visual C++就是这样做的,它实际上并没有编译任何东西,直到链接器运行并且可以访问所有代码.其他编译器也有类似的选择.

Answer 2

sqlite使用这个想法.在开发过程中,它使用传统的源结构.但实际使用中有一个巨大的c文件(112k行).他们这样做是为了最大化优化.声称性能提升约5-10%

http://www.sqlite.org/amalgamation.html

Answer 3

我们(以及其他一些游戏公司)确实通过制作一个uber-.CPP来尝试#include所有其他游戏; 这是一种已知的技术.在我们的例子中,它似乎并没有对运行时产生太大影响,但是你提到的编译时缺点却完全是瘫痪的.在每次更改后编译半小时,就无法有效地进行迭代.(这是应用程序被分为十几个不同的库.)

我们尝试使用不同的配置,这样我们在调试时会有多个.objs,然后只在release-opt版本中使用uber-CPP,但后来又遇到了编译器内存不足的问题.对于足够大的应用程序,工具根本无法编译数百万行cpp文件.

我们也尝试了LTCG,这提供了一个小但很好的运行时提升,在极少数情况下它不会在链接阶段简单地崩溃.

Answer 4

有趣的问题!你肯定是正确的,所有列出的缺点都是开发人员特有的.但是,我建议弱势开发者生产优质产品的可能性要小得多.可能没有运行时缺点,但想象一下,如果每次编译需要数小时(甚至数天)才能完成,开发人员不愿意进行小的更改.

我将从"过早优化"的角度来看待这个问题:多个文件中的模块化代码使程序员的工作更轻松,因此以这种方式做事情有明显的好处.只有当一个特定的应用程序运行得太慢时,并且可以证明内联所有内容都有一个明显的改进,我甚至会考虑给开发人员带来不便.即使这样,也会在大部分开发完成之后(以便可以测量),并且可能只对生产构建进行.

Answer 5

这是半相关的,但请注意,Visual C++确实具有跨模块优化的能力,包括跨模块的内联.有关信息,请参阅http://msdn.microsoft.com/en-us/library/0zza0de8%28VS.80%29.aspx.

为了添加原始问题的答案,假设优化器足够智能(因此在Visual Studio中将其添加为优化选项),我认为在运行时不会出现缺点.只需使用足够智能的编译器自动完成,而不会产生您提到的所有问题.:)

Answer 6

这几乎就是整个程序优化和链接时间代码生成 (LTCG) 背后的理念：全局知识带来的最佳优化机会。

从实际的角度来看，这有点痛苦，因为现在您所做的每一个更改都需要重新编译整个源代码树。一般来说，您需要优化构建的频率低于您需要进行任意更改的频率。

我在 Metrowerks 时代尝试过这个（使用“Unity”风格构建非常容易设置），但编译从未完成。我提到它只是为了指出这是一个工作流程设置，可能会以他们没有预料到的方式对工具链造成负担。

Answer 7

好处不大 在一个适合现代平台的良好编译器上，inline只会影响极少数的功能。这只是对编译器的一个提示，现代编译器相当擅长自己做出这个决定，并且函数调用的开销已经变得相当小（通常，内联的主要好处不是减少调用开销，而是开放进一步优化）。

编译时间 然而，由于内联也会改变语义，因此您必须将#include所有内容放入一个巨大的编译单元中。这通常会显着增加编译时间，这对于大型项目来说是一个杀手。

代码大小
如果您放弃当前的桌面平台及其高性能编译器，情况会发生很大变化。在这种情况下，由不太聪明的编译器生成的代码大小增加将是一个问题 - 以至于它使代码显着变慢。在嵌入式平台上，代码大小通常是第一个限制。

尽管如此，一些项目可以并且确实从“内联一切”中获利。它为您提供了与链接时间优化相同的效果，至少如果您的编译器不盲目遵循inline.