消息值，托管字符串，扰乱代码及其它

核心提示： 所有这些要点是托管文字量更快，为了弄清楚它到底有多快，消息值，托管字符串，扰乱代码及其它(5)，我写了另一个托管 C++ 程序，StrTime，5000万次（记住“字符串暂留”）为了证明这一点，我修改了 StrTime (StrTime2)以显示托管 String

所有这些要点是托管文字量更快。为了弄清楚它到底有多快，我写了另一个托管 C++ 程序，StrTime，它分配了一大批字符串并报告花了多长时间。我 使用了我在 2004年6月专栏中的 ShowTime 类：

_stprintf(msg， _T("Test 1: Allocate %d strings using LPCTSTR"),num);
ShowTime st(msg);
for (int i=0; i<num; i++) {
　　String* s = new String(_T("This is a TCHAR string"));
}　　　

StrTime 则使用托管 S 文字量做同一件事。下面是结果：

C:\>StrTime 50000000
Test 1: Allocate 50000000 strings using LPCTSTR: 32797 msec
Test 2: Allocate 50000000 strings using .NET S literal: 100 msec

Wow！正如你所看到的，S 字符串快得多。但是，嗨——等一下，这里到底发生了什么？ldstr 真的快327倍吗？这个测试值得可疑有两个原因。首先，函数调用不应该如此 昂贵；其次，我的机器只有 785MB，我真的分配了5000万个字符串吗？当然不是！因为变量s在循环内部存活，每次反复它都超出范围——这使得它满足垃圾收集 器的条件。事实上，你可以写如下的程序并且它永远循环而不会耗尽内存：

while (1) {
　　String* s = new String(L"foo");
}

在这个测试中，S 文字量表现得如此之快的主要原因是 C++ 文字量调用 newobj 来创建新的对象，尽管 S 文字量生成 ldstr，它只简单地将相同 的对象引用一次又一次地压入栈中，5000万次（记住“字符串暂留”）为了证明这一点，我修改了 StrTime (StrTime2)以显示托管 String 的实际地址。为此，你需要使用 GCHandle：