IIS 7 连接 C# 字符串真的很慢答案

【问题标题】：IIS 7 really slow concating C# stringsIIS 7 连接 C# 字符串真的很慢
【发布时间】：2012-11-27 00:10:08
【问题描述】：

我们有一个用大量字符串连接实现的大型系统 - 它无处不在。

我们编写了一个在循环中连接字符串的快速页面。这在我们的 dev boxen（调试关闭）和我们的测试虚拟机上运行 3.3 秒。但是在生产 (IIS7) 上，它运行时间为 15.7 秒。

谁能建议我们可以在服务器端查看哪些内容（IIS 设置、内存设置等）来解决这个问题？

仅供参考 - 服务器有大量空闲内存和空闲 CPU 周期 - 所以这不是资源问题。 重写所有代码以使用 string.Join 或 StringBuilder 不在预算之内。

【问题讨论】：

如何连接字符串，使用 + 或使用 StringBuilder 类？
Sergey - 本质上是 sStringMain += sStringSub;
您能否展示更可行的代码，让我们可以看到您在做什么，而不是让我们猜测或玩读心术......？
你确定你只是不小心把调试留在你的生产机器上吗？
@Jack “我们写了一个快速页面，在循环中连接字符串”，所以快速查找替换并使用StringBuilder。否则，您将不得不为我们提供代码。很可能这不是代码问题。

标签： c# string memory iis-7

【解决方案1】：

这会在内存中创建许多微小的字符串对象，这些对象需要稍后被垃圾收集器收集。替换为

  var sMain = new StringBuilder();
  while (something)
  {
    sMain.Append(sStringSub);
    // ...
  }

  // Call sMain.ToString() when you need the whole string

【讨论】：

正如我所说，此选项不在预算中，也不能解释差异 - 请在发布答案之前阅读问题。
我会预先为 StringBuilder 分配更多内存。默认情况下，它包含 16 个字符。一旦必须为更大的数据重新分配新的内存块，它实际上会同样严重地影响性能。
@SimonWhitehead 这不是 .NET 中 StringBuilder 的工作方式。与 List 类似，StringBuilder 可以扩展而无需将旧内容复制到新数组中。否则 StringBuilder 将毫无用处。我个人尝试设置 StringBuilder 的创建容量，如果我大致了解它应该有多大，但这是一个无法检测到的微观性能优化。
@Trisped 不正确。 ILSpy 显示，如果容量（默认值：internal const int DefaultCapacity = 16;）被消耗，它将调用它的内部方法private void ExpandByABlock(int minBlockCharCount)，该方法分配一个新的char[]（.NET 4，string 在.NET 2 中）并自行重建。
@SimonWhitehead 无论哪种方式，您的声明“一旦必须为更大的数据重新分配新的内存块，它实际上会同样严重地影响性能。”不正确。

【解决方案2】：

不敢相信我是第一个推荐RedGates Profiling Tools的人。

这将告诉您究竟是什么在服务器上与开发 PC 上花费了这么多时间。

字符串是存储在托管堆上的引用类型，因此受垃圾回收的约束。 GC 将在 GC 第一次检测到它无法释放内存时将您的字符串提升几代（0,1,2）。如果您查看CLR Profiler，我敢打赌您会看到分配给第 2 代的大量字符串。

重写所有代码使用string.Join或StringBuilder不在预算。

它是否在预算内并不重要。如果一个应用程序需要 15 秒来响应，那么没有人会想要使用它，你也不会赚钱。你将不得不改变一些东西。

如果没有 Profiler 的踪迹，它就像在黑暗中拍摄……我最好的猜测是开发 PC 有一个 SSD。

即使字符串是不可变的，并且大部分内存可能指的是 GC 无法收集的已连接的字符串。我仍然不认为这是内存问题，我敢打赌它与 I/O 有关，但分析器跟踪会确认。

【讨论】：

【解决方案3】：

将您的开发箱上的网站设置与您的生产箱不同。有很多事情可能会导致不同，从工作线程数到最大内存大小。如果超过这些阈值，IIS 将回收工作人员。

另外，您在开发盒上使用的是 IIS 还是 Cassini？

检查您的应用没有在调试模式下运行。

【讨论】：