什么时候一个Delphi应用程序对于单个EXE来说太大了？

Question

如果我将整个Delphi应用程序编译为一个可执行文件，该文件将增长到5MB、10MB，甚至更多。什么时候太大了？这有什么问题呢？这是一个商业应用程序，目前在Delphi XE上。

我知道使用运行时包构建的选项。这听起来像是一个好主意，但我在这里看到了一些评论，指出其中存在一些问题和缺点。

Answer 1

我不知道应用程序的exe大小有什么问题。我目前在一个应用程序中工作，它的exe大约是60MB，没有任何问题。

我所知道的唯一限制是可用内存的限制。使用运行时包的应用程序将消耗更多的工作内存，因为所有运行时包都是在应用程序启动时加载的。而且这些包包含了很多代码，这些代码在你的应用程序中是不会被使用的。

我真的很喜欢运行时包的想法，但我不喜欢Delphi中的实现。一个主要的缺点是，你的应用程序必须附带一堆包，这使得它很难维护。

Answer 2

一个Delphi应用程序永远不会真正的太大()。

但是，exe越大，重新分发文件的难度就越大。

此外，如果可执行文件位于网络磁盘上，启动时间可能会受到影响。

导致exe增长的因素很多：

启用调试信息的

• (将或多或少地使exe大小加倍)。

禁止在最终可执行文件中包含调试信息(参见上面的屏幕截图)。

包含位图(在imagelist或类似组件中)的

• 也会显著增加可执行文件。包含资源(使用自定义*.res)的
• 文件将增大大小。

我建议不要将资源放在单独的dll中。

这将使您的应用程序复杂化，同时不会减少加载时间和分发问题。

在生产代码中关闭调试信息是必须的。

如果您使用的是Delphi-2010或更高版本，则可以选择包含png格式的图像。

这将比旧的skool位图占用更少的空间。

不过，只要你的应用小于30MB，我就不会太担心文件大小。

条带RTTI信息

David建议剥离RTTI信息(这将禁用实时绑定和其他一些高级内容)，请参阅：Reduce exe file

根据David的说法，它节省了大约30%的exe大小。

Exe-size只会增加加载时间

更重要的是您的应用程序分配为存储的数据量。

您在这里使用(或浪费)的空间量对应用程序性能的影响将远远大于原始exe大小。

Strategy or tools to find "non-leak" memory usage problems in Delphi?

优化的更好方法是确保不会泄漏资源

How to activate ReportMemoryLeaksOnShutdown only in debug mode?

Windows API calls memory leak detection

使用智能数据结构和算法

在这里，它变得太普遍了，无法真正缩小范围，但使用O(缓慢增加)而不是O(浪费增加)的算法。

Big-O for Eight Year Olds?

并尝试通过仅获取您需要的数据来限制内存使用，而不是您的可能需要但可能永远不会需要的所有数据。

Delphi data structures

等等。

Answer 3

使用RELEASE Build来减少执行大小，使用performance.also来增加运行时包来减少exe文件，但是使用运行时包来增加包(安装)文件大小。