Delphi应用程序将来会变得更小吗

delphi win32 exe大小已经是~850 kb，他们是否有将exe大小缩小一点的路线图（我知道这个大小是因为vcl unicode RTTI和更多），delphi编译整个单元，甚至只需要单元中的一个小函数。因此，是否有任何设施可以这样做，或者有第三方产品（我知道kol和mck也这样做）

我怀疑exe大小是否是德尔福团队，甚至是大多数用户关心的问题。正如您所注意到的，unicode和新的RTTI增加了大小，虽然您可以使用新的RTTI，但实际上您对此无能为力

一般来说，每一个新的Delphi版本都会产生更大的EXE，我看不出这种趋势会改变

至于编译不正确的整个单元，除非编译包，否则编译器不会包含未使用的方法和声明

如果exe大小很重要，您没有太多选择。如果您不需要unicode和其他新功能，那么可以选择使用D2007、D7甚至D2

您可以使用exe打包程序，如UPX

如果您构建一组应用程序，您可以通过使用共享包来减少总大小

另外，请查看以下内容：

---

您当然不应该期望未来64位Delphi版本的exe大小小于当前32位Delphi exe文件

---

相反：指针和指针大小的类型的大小将增加一倍，而其他数据结构的大小可能会由于填充而增加（以满足对齐要求）。所有这些都被编译到可执行文件中，其大小将因此而增长。

路径看起来是EXE，但将来会变得更大。应用程序大小变得不那么重要，因为磁盘大小、带宽和内存占用在Windows世界中很少成为问题。exe大小和exe优化之间总是有一个折衷（一些优化技术可以使exe更大），64位可执行文件可能会更大一些。此外，语言的改进可能需要存储更多关于代码本身的数据（即RTTI信息）。有一些技术可以保持exe的小尺寸，但它们通常需要绕过大多数Delphi OOP和RAD特性和库。除非您有非常特殊的需求，否则exe大小很少是一个问题（尽管我知道世界上某些地方的带宽仍然很重要，可能还有磁盘空间）

---

无论如何，这不是真的德尔福链接器将导入一个完整的单位。未使用的呼叫将被删除，尽管不是您希望的所有呼叫。dcu将作为一个整体进行编译，但只将所需的代码移动到已编译的可执行文件中。有些事情可能取决于您的编译选项。你激活了优化选项了吗？

我想这方面的免费Pascal常见问题也适用于Delphi：

我不知道你关于.EXE大小的问题与此有什么关系

在您的问题中，假设某个单元始终完全包含在您的.EXE中，即使实际上只使用了该单元的一小部分，这显然是错误的。
Delphi同时具有代码优化器和链接优化器。
如果您的.EXE中的某个单元的代码实际上没有被使用，则后者将不包括该单元的代码

您更一般的问题“他们是否有使exe大小变小的路线图”可以用一个简单的“否”来回答。
报告没有包括这一点

---

--jeroen

delphi 2010支持guesture和unicode，但如果我不想，我可以离开它编译itkol和mck很好，但缺乏设施，在十年前的D7之后没有支持，一个10 GB的硬盘可以存储100000个这样的程序。现在，范围以TB为单位；做你的计算。过早优化是万恶之源（D.E.克努特）。@Lie:你在逃避眼前的争论。即使考虑到Unicode迁移，也没有逻辑上的理由说明二进制文件应该如此显著地增长。VS2010证明了代码不必随着新的编译器而增长。@Lie：你不认为较小的二进制文件意味着更少的代码，你会同意最快的代码是不需要运行的代码吗？这是我的主要观点。我意识到，出于经济原因，人们必须牺牲一些速度或规模，以获得更快的开发或更好的可维护性。但只是到目前为止。例如，还没有人提出逻辑上的理由来解释为什么用Delphi7编译的程序比用Delphi XE编译的二进制程序小四倍。Unicode也不是令人信服的理由，因为大多数相关的膨胀都在VCL中，但这段代码没有使用VCL。“我怀疑exe大小是Delphi团队，甚至是大多数用户关心的问题。”我同意。在进入数兆字节范围之前，不会出现真正的减速。