为什么生成的二进制文件如此之大?

wro*_*ame 11 c++ size binaries

为什么编译C++程序时生成的二进制文件如此之大(如同源代码文件大小的10倍)?与不需要这种编译的解释语言相比,它提供了哪些优势(因此程序大小只是代码文件的大小)?

Ton*_*roy 9

现代解释语言通常会将代码编译为某种表示形式,以便更快地执行...它可能无法写入磁盘,但肯定无法保证程序以更紧凑的形式表示.有些解释器会全力以赴并生成机器代码(例如Java JIT).然后是解释器本身就位于内存中,这可能很大.

几点:

  • 源代码中的命令越复杂,执行它们可能需要的机器代码操作就越多.因此,更高级别的语言特征往往具有更高的编译代码与源代码的比率.这不一定是坏事:把它看成"我只说一点关于我想要做什么,它推断所有这些必要的步骤".编程中的挑战是确保它们是必要的 - 这需要良好的库和程序设计.
  • 编译器经常故意决定交换一些可执行的大小以获得更快的预期执行速度:内联vs外线代码是这种折衷的一部分,尽管对于小功能来说,两者都不能始终更紧凑.
  • 更复杂的运行时环境(例如,添加对C++异常的支持)可能涉及一些额外的代码,这些代码在程序首次开始为该语言特性构建必要的环境时运行.
  • 库功能可能无法比较.除了那些你很可能不得不追踪自己并且非常了解使用(例如XML,PDF解析,OpenGL)的附加库,语言通常会悄悄地使用支持库来实现语言功能和功能.任何这些都可能令人惊讶地大.
    • 例如,许多解释器只是暴露C库的printf()语句或类似的东西,而对于输出格式化C++有ostream- 一个更复杂,可扩展和类型安全的系统,具有(更好或更坏)跨函数调用的持久状态,查询和设置的例程该状态,可定制的缓冲,可自定义的字符类型和本地化的附加层,以及通常许多小内联函数,可以根据确切的用途和编译器设置导致更小更大的程序.什么是最好的取决于您的应用程序和内存与性能目标.
  • 内置语言语句的编译方式可能不同:一个switch整数表达式,并且有100个案例标签随机分布在1到1000之间:一个编译器/语言可能决定"打包"100个案例并进行二进制搜索以匹配,另一个使用一个稀疏填充的1000个元素的数组,并进行直接索引(这会浪费可执行文件中的空间,但通常会使代码更快).因此,很难根据可执行文件大小得出结论.

通常,随着程序变得越来越大和越来越复杂,内存使用和执行速度变得越来越重要.您没有看到以解释语言编写的操作系统,企业Web服务器或全功能商用文字处理器等系统,因为它们没有可扩展性.


Dar*_*rov 7

解释型语言假定可以使用解释器,而编译程序在大多数情况下是独立的.

  • @William:编译后的代码在运行时通常依赖于共享库/DLL,所以它并不是那么明确。 (2认同)