为什么使用 Debug 语句会使代码运行很慢？答案

【问题标题】：Why does using Debug statements make code run really slow?为什么使用 Debug 语句会使代码运行很慢？
【发布时间】：2011-03-17 04:59:37
【问题描述】：

我有这个循环

        // go through each alumni
        foreach (esDL.Alumni currAlumni in allAlumnis)
        {
            ... loop logic

        }

这几乎是瞬间运行。

当我像这样输入跟踪或调试语句时......

        foreach (esDL.Alumni currAlumni in allAlumnis)
        {
            ... same loop logic

            Trace.WriteLine("hi");
            Trace.Indent();
            Trace.WriteLine("written");

        }

这大大减慢了速度。用于跟踪或调试

这是为什么呢？有没有办法防止这种情况发生？

我只附加了默认监听器。

编辑 - 经过更多测试，我发现 Trace.Indent 让它变得非常非常慢。但是只有 WriteLine 仍然会大大降低性能。 Indent 方法有什么问题？

【问题讨论】：

你配置了什么样的跟踪监听器？
只是默认的TraceListener
糟糕，你这么说。那么“明显”慢了多少？喜欢测量，还是只是观察？
只是观察。我有 2000 个预加载行。没有跟踪语句，它不到一秒。使用 writelines，可能大约 10 秒，使用缩进，超过 1 分钟。
由于我没有对 Debug 类进行任何自定义，您可以只创建一个带有循环的小型控制台应用程序，然后自己查看性能下降。

标签： .net performance debugging trace

【解决方案1】：

任何量的调试都可能会减慢您的程序速度，甚至会以十分之一的速度运行。它必须同时向您的侦听器（您似乎没有）和默认侦听器发送消息，默认侦听器将其转发到 Debugger.Log 和 Win32 OutputDebugString - 难怪它会减慢一点:-)

至于为什么缩进可能会产生很大的影响，你实际上是在那个循环的某个地方取消缩进吗？如果您不是，并且您有 2000 个项目（根据您在其他地方的评论），那么当您接近结尾时，每行前面将有相当多的空间（每行平均 1000 个缩进很可能有问题）。

【讨论】：

谢谢！缩进的东西肯定是因为那 - 这太愚蠢了！
虽然我也想问，为什么调试这么慢？如果我只想创建可以在应用程序本身中处理的日志，我应该只使用 StringBuilder 吗？它会快得多，唯一的问题是我不能使用有用的缩进方法。
做某事总是比什么都不做要慢 :-) 如果你真的想自己动手，我倾向于输入if (trace == true) log ("my message");，这样就没有函数了如果不需要跟踪，请致电。这不是 OO 方式，但如果您追求原始性能，有时这是必要的。

【解决方案2】：

我假设您在没有调用 Trace.Unndent() 的情况下为每一行调用 Trace.Indent()，这使得缩进级别不断增加。

假设您有 2000 行要处理，并且您当前正在处理第 1000 行，这使得 IndentLevel 为 1000。假设缩进由 '\t' 一个 unicode 字符表示（假设 UTF-16，即每个字符 2 个字节）。然后，此时，要创建调试跟踪，必须为迭代中的特定跟踪分配大约 2KB 的内存。分配该大小的内存并不是便宜的操作，而且您实际上是在每次迭代中增加跟踪条目的大小。

此外，我不清楚垃圾回收何时释放内存。换句话说，当底层调试基础设施将使用内存完成时。由于您非常频繁地创建长跟踪条目，因此很可能很快耗尽 Gen1 堆。当垃圾收集器启动并且调试基础设施未处理某些跟踪行时，它们也将移动到 Gen2 堆。这将增加您的流程的工作集大小，这可能会再次减慢您的流程。

您可能需要检查应用程序的 .NET 性能计数器。我会检查 Gen1、Gen2、Gen3 堆的大小、堆总大小、Gen1、Gen2、Gen3 垃圾收集的数量。您的应用程序执行的 Gen 垃圾收集越多，您的应用程序也会越慢。

不过，这只是我的粗略猜测。

【讨论】：