为什么在循环期间追加到TextBox.Text每次迭代都占用更多内存？

简短问题

我有一个运行18万次的循环。在每次迭代结束时，都应将结果附加到TextBox，并实时更新。

使用MyTextBox.Text += someValue将导致应用程序占用大量内存，并且在记录了数千条之后耗尽了可用内存。

有没有一种更有效的方式将文本附加到TextBox.Text18万次？

编辑我真的不在乎这种特殊情况的结果，但是我想知道为什么这似乎是一个内存消耗，以及是否存在一种将文本追加到TextBox的更有效的方法。

长（原始）问题

我有一个小应用程序，可以读取CSV文件中的ID号列表，并为每个文件生成PDF报告。生成每个pdf文件后，将在其后ResultsTextBox.Text附加已处理且已成功处理的报告的ID号。该进程在后台线程上运行，因此，在处理项目时，ResultsTextBox会实时更新

我目前正在针对180,000个ID号运行该应用程序，但是随着时间的流逝，该应用程序占用的内存呈指数增长。它的开始时间约为90K，但是大约3000条记录占用了大约250MB的内存，而4000条记录则占用了大约500 MB的内存。

如果我注释掉对“结果”文本框的更新，则内存保持相对稳定，大约为90K，因此我可以假定写入ResultsText.Text += someValue是导致它消耗内存的原因。

我的问题是，为什么呢？将数据追加到不占用内存的TextBox.Text的更好方法是什么？

我的代码如下所示：

try
{
    report.SetParameterValue("Id", id);

    report.ExportToDisk(ExportFormatType.PortableDocFormat,
        string.Format(@"{0}\{1}.pdf", new object[] { outputLocation, id}));

    // ResultsText.Text += string.Format("Exported {0}\r\n", id);
}
catch (Exception ex)
{
    ErrorsText.Text += string.Format("Failed to export {0}: {1}\r\n", 
        new object[] { id, ex.Message });
}

值得一提的是，该应用程序是一次性的，生成所有报告都将花费几个小时（或几天：)没关系。我主要担心的是，如果达到系统内存限制，它将停止运行。

我可以将结果文本框的更新注释掉以运行该程序，但我想知道是否存在一种将内存附加到TextBox.Text以后项目的更有效内存的方法。

我怀疑内存使用量如此之大是因为文本框维护一个堆栈，以便用户可以撤消/重做文本。您似乎不需要该功能，因此请尝试将其设置IsUndoEnabled为false。

使用TextBox.AppendText(someValue)代替TextBox.Text += someValue。由于它位于TextBox而不是TextBox.Text上，因此很容易错过。与StringBuilder一样，这将避免每次添加内容时都创建整个文本的副本。

看到这与IsUndoEnabledkeyboardP答案中的标志相比如何会很有趣。

不要直接附加到text属性。使用StringBuilder进行附加，然后在完成后，将.text设置为来自stringbuilder的最终字符串

代替使用文本框，我将执行以下操作：

1. 以防万一，打开一个文本文件并将错误流式传输到日志文件。
2. 使用列表框控件表示错误，以避免复制潜在的大量字符串。

我个人总是使用string.Concat*。我记得几年前在Stack Overflow上读过一个问题，该问题具有比较常用方法的性能分析统计数据，并且（似乎）想起了这一点string.Concat。

尽管如此，我能找到的最好的是这个参考问题和这个特定String.Format与StringBuilder问题的问题，其中提到String.Format在StringBuilder内部使用。这使我想知道您的记忆猪是否在其他地方。

**基于James的评论，我应该提一下，因为我专注于基于Web的开发，所以我从不进行繁琐的字符串格式化。*

也许重新考虑TextBox？包含字符串Items的ListBox可能会表现更好。

但是主要的问题似乎是要求：显示180,000个项目不能针对（人类）用户，也不能在“实时”中进行更改。

最好的方法是显示数据样本或进度指示器。

当您确实想将其转储给不良用户时，将更新批处理字符串。没有用户可以每秒发现超过2或3个更改。因此，如果您每秒产生100个，请每组50个。

有人提到了它，但没有人直接说出来，这令人惊讶。字符串是不可变的，这意味着创建后无法修改字符串。因此，每次连接到现有String时，都需要创建一个新的String Object。显然还需要创建与该String对象关联的内存，当您的String变得越来越大时，该内存可能会变得昂贵。在大学里，我曾经犯过一个业余错误，即在执行霍夫曼编码压缩的Java程序中串联字符串。当您串联大量文本时，如果您仅使用StringBuilder（如本文中的某些内容所述），那么字符串串联确实会伤害您。

按照建议使用StringBuilder。尝试估计最终的字符串大小，然后在实例化StringBuilder时使用该数字。StringBuilder sb = new StringBuilder（estSize）;

更新TextBox时，只需使用赋值即可，例如：textbox.text = sb.ToString（）;

注意上面的跨线程操作。但是，请使用BeginInvoke。UI更新时无需阻止后台线程。

A）介绍：已经提到，使用 StringBuilder

B）点：不要更新太频繁，即

DateTime dtLastUpdate = DateTime.MinValue;

while (condition)
{
    DoSomeWork();
    if (DateTime.Now - dtLastUpdate > TimeSpan.FromSeconds(2))
    {
        _form.Invoke(() => {textBox.Text = myStringBuilder.ToString()});
        dtLastUpdate = DateTime.Now;
    }
}

C）如果这是一次工作，请使用x64架构将其限制在2Gb以内。

StringBuilderinViewModel将避免字符串重新绑定混乱，并将其绑定到MyTextBox.Text。这种情况将使性能提高很多倍，并减少内存使用量。

尚未提及的是，即使您在后台线程中执行操作，UI元素本身的更新也必须在主线程本身上进行（无论如何在WinForms中）。

更新文本框时，您是否有任何看起来像这样的代码

if(textbox.dispatcher.checkAccess()){
    textbox.text += "whatever";
}else{
    textbox.dispatcher.invoke(...);
}

如果是这样，那么您的后台操作肯定会受到UI更新的限制。

我建议您的背景操作如上所述使用StringBuilder，但不要在每个周期都更新文本框，而是尝试定期更新它以查看它是否为您提高了性能。

编辑注意：尚未使用WPF。

您说内存成倍增长。不，它是二次增长，即多项式增长，不如指数增长那么剧烈。

您正在创建包含以下项目数的字符串：

1 + 2 + 3 + 4 + 5 ... + n = (n^2 + n) /2.

随着n = 180,000您获得的总内存分配16,200,090,000 items，即16.2 billion items！不会立即分配该内存，但是对于GC（垃圾收集器）来说，这是很多清理工作！

另外，请记住，必须将以前的字符串（正在增长的字符串）复制到新的字符串中179,999次。复制的字节总数与n^2！

正如其他人建议的那样，请改用ListBox。在这里，您可以追加新字符串而无需创建巨大的字符串。AStringBuild没有帮助，因为您也想显示中间结果。