这些天是否真的有理由使用动态链接和二进制分发？
对于二进制发行版，可以选择在源代码中分发所有内容，让平台选择是否编译二进制文件。但它是否可用取决于今天的计算机从源代码编译得有多好。
动态链接属于这个问题，因为它允许在二进制文件中分发库。
那么，编译器可以展示出多么出色的性能？优化与否？如何从编译器中获得更好的性能呢？
答案 0 :(得分：4)
您的问题有点不清楚，但似乎与两个不相关的项目有关。将组件分解为动态和静态链接库确实使编译在许多情况下更快。然而，动态和静态库并非为此目的而发明。它们的发明是为了在功能和程序之间提供可重用的组件。不要更快地编译。
答案 1 :(得分：2)
真实原因提供软件的二进制分发。撇开通过编译来混淆软件的业务问题，以便不以非常清晰的方式提供专有逻辑，它使用户更简单，，软件适用于谁。
我真的不喜欢以源代码格式获取GCC，Gnome，PHP和其他一百万个其他软件包，除非我正在开发该软件。即使在我的四核机器上，编译也需要时间。我更倾向于只是移动一些二进制blob。
还要记住（至少在Linux系统上）创建二进制分发版允许已经过测试的一致且稳定的系统。创建二进制发行版是向用户提供的最佳直接翻译测试软件配置。
鉴于许多JIT / Interpreted语言的运行速度约为C的1/2（粗略地说，确定有些人做得更好），我宁愿拥有软件的机器代码分发，也不愿看到用Java / C＃编写的所有代码。特别是当我不需要看代码时。不要介意下载源代码分发和按需编译。作为用户（和开发人员），RPM / .debs要简单得多。
所以这种答案“这些天人们真正有理由使用动态链接和二进制分发吗？”。动态库的问题并不是真正的问题。运行时符号解析不会过多降低性能。像Apache这样的项目和无数其他项目如何处理模块架构呢？ （嘿，他们总是可以有一个内置的编译器/解释器，链接器，加载器并手动完成！颤抖）
软件编译一次，并使用了很多
至于使编译器更快，这取决于正在编译的语言的语义，以及分析的繁重工作。您可以编写一个非常快速的C编译器，但代码可能不是最佳的，因此运行速度较慢且占用内存较大。考虑到软件编译一次并且经常运行，我宁愿软件需要花费1小时以上的时间来编译，但以后会节省时间。但这并不重要，因为我们有二进制分布。
答案 2 :(得分：2)
gentoo Linux distribution就是这么做的。我们接近分配源而不是二进制文件变得更便宜的程度。目前，还有一些问题需要解决：
make这样的工具允许并行编译代码。但它仍然比将文件从安装介质复制到磁盘要慢。慢了很多。OSS解决了问题＃3。 gentoo解决了＃4。现在，我们只是坚持＃2，真的。今天的CPU太慢，无法从源代码运行类似游戏或MS Office的东西。
答案 3 :(得分：1)
在阅读您的问题时，有三件事情要记住：
动态链接与二进制分发无关。
如果您希望编译尽可能快，则无法在编译时使用良好的优化。 （即，制作快速编译器，删除所有优化）
JIT编译器似乎能够在执行速度和编译速度之间实现良好的折衷，但是它们运行的代码是作为二进制文件部署和分发的，因为仍然可以在第一次编译时运行一些优化（最昂贵的）并且因为你真的不希望在每台计算机上都有一个完整的工具链来分发源代码。
答案 4 :(得分：1)
动态链接还允许运行时发现已安装的组件，这在至少两种情况下很有用：
答案 5 :(得分：0)
当使用单个二进制目标重新编译项目时，通常只更改文件，因为在链接之前重新编译最后的编译，因此具有单独的二进制目标应该会改善整个编译时间，但只是略微改进。
答案 6 :(得分：0)
这取决于您正在构建的项目类型。
一些单词编辑器等待输入比计算多100倍不需要二进制，但实时游戏肯定需要最后一点速度，尤其是那些有ai玩家的速度。
还有更多的情况：操作系统，图形编辑器（你不想等待5分钟来处理效果），模拟器，研究用品。因此，计算机可以实现的大多数有趣的事情都需要在运行时加速，而不是编译时间。