为什么静态库只是一包目标文件，没有任何通常的相互依赖的优化或重新排序？
当链接共享库（或至少是 Windows DLL）时，可以进行大量优化，并且所有函数和类都被放在一起并重新组织以获得最佳性能（或者我认为/希望如此）。
为什么静态库只是一包对象？对于链接器（时间和性能方面）来说，拥有目标文件中包含的变量、函数、类等的列表不是更好吗？因此，当链接使用该库的可执行文件或共享对象时，可以从静态库中相互依赖的东西上已经执行的优化传递中获益？
静态库的创建不会花费更长的时间（无论如何只能进行有限数量的优化），但使用该库的后续构建步骤将更快/更优化。
PS：我在这里主要谈论链接时间优化，但由于所有流行的工具链都以拥有此功能为荣，我确信这个问题会以某种方式弹出？请不要回答这个问题：一直都是这样，或者兼容性，没有人想过要改变它。这不是我要找的...
When linking a shared library (or at least a Windows DLL), lots of optimizations are possible, and all functions and classes are thrown together and reorganized for optimal performance (or so I would think/hope).
Why are static libraries only a bag of objects? Wouldn't it be better for the linker (both time and performance-wise) to have list of variables, functions, classes etc. that are contained within the object files, so when linking an executable or a shared object that uses this library can profit from an already performed optimization pass on interdependent things in the static library?
The static library creation would not take much longer (only a limited number of optimizations would be possible anyhow), but subsequent build steps using this library would be much faster/optimal.
PS: I'm mostly talking link-time-optimization here, but as all popular toolchains are proud to have this feature, I'm sure this question would pop up somehow? Please don't answer this question with: that's how it's always been, and or compatibility nobody ever thought to change it. That's not what I'm looking for...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
链接时代码生成和链接前优化之间存在冲突。
假设您在该库中仅使用固定参数
Foo(12)调用函数 Foo 一次。 LTCG 现在允许将 Foo() 实现减少到单一情况，从而使您之前可能收集的所有优化和调用树信息无效。考虑到这一点，只有
Foo()不调用Bar()的信息才能保留。不过，我不知道这会如何显着降低链路阶段压力。排序信息同样受到分析器引导的优化：哪些函数是需要分组在一起的热点只能由最终的二进制文件确定。
一般来说，优化似乎正在从先前的阶段转向链接阶段，虽然您建议的优化是可行的，但当您将其与场景数量进行权衡时，它可能不会得到回报。这可以使用并且代码中的额外复杂性（大致与错误数量成正比）
There is a conflict between link time code generation and pre-link optimizations.
Assume from that library you call a function Foo only once with a fixed argument:
Foo(12). LTCG now allows to reduce the Foo() implementation to that single case, invalidating all optimizations and call tree information you might previously have gathered.With that in mind only the information that
Foo()does not callBar()can carry over. I don't see how that would significantly reduce link stage pressure, though.Ordering information is similarly subject to profiler-guided optimizations: which functions are hot spots that need to be grouped together can only be determined by the final binary.
Generally it seems that optimization is moving towards the link stage, away from previous stages - and while the optimizations you suggest are feasible, it probably wouldn't pay off when you weight it against the amount of scenarios where this could be used and the additional complexity in code (roughly proportional to number of bugs)
这些文件中有原型。他们的行为可能就像你提到的列表一样
There are prototypes in those files. They probably act like the list you mentioned