代码之家  ›  专栏  ›  技术社区  ›  Oliver Giesen

Delphi2009切换到Unicode(/utf16)对可执行文件大小和内存占用有什么影响(如果有)?

  •  2
  • Oliver Giesen  · 技术社区  · 16 年前

    以下是“毫无疑问太蠢”部门的一个:

    嗯,正如主题所说:有影响吗?如果有的话,多少钱?我的代码和dfm资源中的所有字符串文本现在是否会占用编译后的二进制文件中两倍的空间?编译应用程序的运行时内存使用情况如何?所有的字符串变量现在占用的RAM是原来的两倍吗?我还需要麻烦吗?

    我记得在一个早期的预发布网络广播中,有人问我这样的问题,但我记不起答案了。因为审判只有14天,所以我不打算在第三方图书馆更新之前(大概一个月后)亲自尝试。

    4 回复  |  直到 16 年前
        1
  •  1
  •   community wiki Craig Stuntz    16 年前

    D2009使用UTF-16作为默认字符串类型,但是如果需要,您可以将变量设置为UTF-8。

    扬格瓦尔茨 discusses the size/speed tradeoff 在一篇好的博客文章中。

    至少从D7开始,dfms中的字符串文本就一直是utf-8。因此,d2009的dfms中的字符串不会增加大小。

        2
  •  0
  •   Oliver Giesen    15 年前

    我现在终于掌握了Delphi2009,在做了必要的调整之后,我的项目现在编译并运行得很好。:)

    为了快速得到结果,我最初不得不对应用程序的一个稍微复杂一些的模块进行注释,这样它还不能100%进行比较,但它已经足够安全,可以预测,尽管源代码中有大量的字符串(过多的调试日志消息),用Delphi2009编译的二进制文件的大小可能会比较粗糙。你和以前一样-如果不是真的更少!

    我想知道,Delphi编译器是否真的对二进制文件或至少对其资源部分执行任何类型的压缩?我真的希望对utf-16字符串文本的更改在这个特定的应用程序中产生更大的影响。这些文本是否真的在二进制文件中存储为(未压缩的)UTF-16?

    我还没有时间研究内存足迹的差异。

    编辑: 不直接与Unicode相关,但绝对相关:Andreas Hausladen最近发表了一篇关于 {$STRINGCHECKS} 编译可执行文件大小的编译器选项(btw:默认情况下打开): http://andy.jgknet.de/blog/?p=487

        3
  •  -1
  •   Mihai Limbășan    15 年前

    我等Unicode VCL等了很多年,终于看到了。我认为大多数应用程序不需要担心大小问题,因为它们没有那么多的字符串文本,或者在内存中存储大量数据。

    可用性问题更为重要,以尽可能证明Unicode的使用是合理的。

    如果一些开发人员想要创建一个小的执行器,他们可以使用ansistring手工优化(如果i18n不是一个问题)。

        4
  •  -2
  •   Neall    16 年前

    我已经很多年没有使用Delphi了,但这可能取决于他们使用什么Unicode编码。对于常规的ASCII字符集,utf8将是完全相同的(当您进入外来字符时,它只使用一个以上的字节)。UTF16可能有点膨胀。