Delphi，字符串与宽字符串内存使用问题，非 unicode VCL (D7)答案

【问题标题】：Delphi, string vs widestring memory usage issue, non-unicode VCL (D7)Delphi，字符串与宽字符串内存使用问题，非 unicode VCL (D7)
【发布时间】：2010-01-02 21:36:04
【问题描述】：

我正在存储一些带有 WideString 参数的类来描述它们（如名称、描述和其他一些）。现在，如果我将所有这些 WideStrings 更改为简单的“字符串”（实际上我使用的是别名，所以我只需要更改一行），内存使用量大约会增加 5%！比以前... 这怎么可能，因为字符串的每个字符都比 WideChar 小两倍？

提前致谢！

米。

【问题讨论】：

你如何衡量你的内存使用情况？
Windows Sysinternals 的进程资源管理器，也是标准进程管理器 (ctrl alt del)
什么计数器？任务管理器的 Mem Usage 在这种情况下是没有用的。在这种情况下，VM Size 更好。

标签： delphi string memory widestring

【解决方案1】：

Delphi 内存管理器不会将所有未使用的内存释放给操作系统。碎片化也可能非常糟糕。两者都取决于您使用的实际内存管理器（FastMM 通常比 D7 中的库存内存管理器更好，但任何内存管理器都可以通过使用内存管理器特定的一系列内存使用模式来屈服）。此外，WideStrings 虽然是 COM 字符串，但不计入引用计数，甚至可能比普通字符串更晚才释放。

在 Delphi 中查询实际内存消息的唯一可靠方法是询问您的 Delphi 程序使用的内存管理器。系统单元中的这个函数会为你做这些：

function GetHeapStatus: THeapStatus

--杰罗恩

编辑：20100104 回应 Marco 的评论：（FastMM 通常比 D7 中的普通内存管理器要好，但是任何内存管理器都可以通过使用内存管理器特定的一系列内存使用模式来屈服）

【讨论】：

+1 堆碎片或 procexplorer 综合症造成的内存使用。顺便说一句，FastMM 并不总是更好。特别是如果代码之前已经调整过，旧的可以更快。因此，虽然 Fastmm 总体上更好，但基准测试规则（测量！）仍然适用。

【解决方案2】：

这是可能的，因为这些字符串几乎肯定构成了用于运行程序的内存的（相对）一小部分。其他空间由句柄、各种对象等使用。

为了举例，假设您在使用 ANSI 字符串时有大约 100KB 的文本，而您将其转换为 Widestrings。只有那 100KB 会受到影响，但那 100KB 并不构成程序内存占用的每一个字节。空间将用于表单、句柄、数字和其他对象，但由于它们在转换中没有被更改，因此它们显然不会比转换前需要更多的内存。

【讨论】：

好的，但是 unicode 和非 unicode 版本之间的 only 区别在于字符串/宽字符串的变化。 没有别的。数据是从同一个文件生成的，并且完全相同（如预期的那样）。数据包含大约 3/4 的字符串。我已经检查了相当大的数据，结果在内存中额外占用了 45 Mb（使用 WideString 时为 43），并且它是完全可重现的。

【解决方案3】：

WideStrings 使用不同的内存管理器（Windows 的）然后 AnsiStrings（Delphi 的）并且引用计数不同。你是如何测量内存使用量的？用什么工具和什么精确的计数器？

【讨论】：

【解决方案4】：

您如何衡量使用的内存？ IIRC WideString 内存是使用 SysAllocString() 分配的，从而绕过了 Delphi 内存管理器。

【讨论】：

【解决方案5】：

Delphi 中的内存管理器总是占用比实际需要更多的内存。就是这样的速度提升。

【讨论】：

【解决方案6】：

不使用 WideString 时，您使用的是 AnsiString 还是 ShortString 类型？您是否有可能使用将所有“String”类型视为 ShortString 的 {$H–} 编译器标志（全局或在某个单元中）进行编译？如果您的字符串是 ShortString 类型并且您没有指定字符串大小，则分配的内存始终为 256 字节。

【讨论】：