10

这简直让我感到困惑。我刚刚下载了 1.5GB 的 Chrome 源代码压缩包。编译的相同代码压缩到大约 50MB。

为什么源代码的大小与可执行文件的大小之间存在如此大的差异？

4

4 回答 4

16

可能导致这种情况的事情清单。

  1. 可执行文件不需要空格、注释或任何漂亮的格式化内容。源代码可能有大量的文档和空白，只是为了使代码可读，所有这些都占用空间。

  2. 源代码可能会带来很多其他代码来测试应用程序。但是这个测试代码永远不会进入最终的应用程序。

  3. 包含在代码中的文档。根据格式、.doc 或 .docx 文件，文档可能很大。

  4. 其他人提到源代码管理注释也可能在代码中。在源代码中包含提交消息也会使文件变大。

  5. 我不知道您是如何/何时进行文件比较的，但如果您是在编译时间之后进行的，那么您可能也在计算中包含了编译工件（ *.o 文件）。因此，您可能会认为源代码只有 750 MB（粗略地说），但它是 1.5GB。

  6. 根据编译器和它的好坏，它可能会生成更少的汇编代码，从而创建更小的文件。虽然我认为今天的大多数编译器都是合理的，但这不应该考虑太多的大小差异。（但我可能错了，我不是编译器）

  7. 如果应用程序正在使用所有库进行静态编译，它会更大，因为现在它必须在其中包含它的依赖项。但是，如果库是动态链接/加载的，则可执行文件本身可能会小得多，因为它只会在运行时链接到库并仅在需要时加载它们。

tarball 是 1.5GB 还是扩展的 tarball 是 1.5GB？

无论如何，这里可能有很多因素在起作用。

于 2012-08-01T21:51:26.750 回答
8

所有源代码文件顶部的版权/许可平均有 1621 字节。Chromium（没有任何 svn/git/object/image 文件）有 73,510 个源文件（为此，我将其保存在.cc、 .h、.cpp、 .idl、.m、 .js、.c、 .py） .

这只是版权声明的 119159710 字节。

或 116366 KB

或 133 兆字节。只是。在.. 版权声明..

更糟糕的是，Chromium 上存在一些开放的错误，表明它们甚至可能违反了他们自己的许可证，因为它们混合了相当多不同风格和版本的开放（以及一些不那么开放）许可证。[1]

资料来源：

[1] https://code.google.com/p/chromium/issues/detail?id=28291

[2] 我使用铬源代码：

Trevors-Mac:src trevor$ 查找 . -名称“*.cc”| wc -l

15941

Trevors-Mac:src trevor$ 查找 . -名称“*.h”| wc -l

26125

Trevors-Mac:src trevor$ 查找 . -名称“*.cpp”| wc -l

5191

Trevors-Mac:src trevor$ 查找 . -名称“*.idl”| wc -l

 881

Trevors-Mac:src trevor$ 查找 . -名称“*.m”| wc -l

 258

Trevors-Mac:src trevor$ 查找 . -name "*.js" | wc -l

13528

Trevors-Mac:src trevor$ 查找 . -名称“*.c”| wc -l

7856

Trevors-Mac:src trevor$ 查找 . -名称“*.py”| wc -l

3988

Trevors-Mac:src 特雷弗$

于 2013-07-11T02:08:24.297 回答
4

好吧，这样说吧：当你编写汇编时，你可能会拼出MOV 0,eax（或者其他什么，我实际上并不知道汇编），然后它会被编译成几个字节。

高级语言通常比它们编译下来的机器代码占用更多的空间，因为它们需要被人类阅读。另一个例子： 2147483647 在源代码中拼写时需要 10 个字节，但在编译时只需要 4 个字节。

于 2012-08-01T21:50:19.193 回答
3

至少部分答案是源代码中的许多单词和符号只对编译器重要，而不是可执行文件。例如，关键字“public”和“private”告诉编译器很多关于允许哪些代码访问哪些变量或其他代码的信息，但在 CPU 上运行的二进制可执行文件级别，没有这样的事情。CPU 只是访问它被告知要访问的任何内存。

于 2012-08-01T21:51:18.587 回答