附加调试器的C＃代码非常慢; MemoryMappedFile的错？

Question

我有一个客户端/服务器应用程序。服务器组件运行，以“远程处理”方式使用WCF（二进制格式化程序，会话对象）。

如果我启动服务器组件并启动客户端，则服务器执行的第一项任务在<0.5秒内完成。

如果我在连接了VS调试器的情况下启动服务器组件，然后启动客户端，则任务需要20秒才能完成。

没有代码更改 - 没有条件编译更改。无论我是否已经编译并运行32位，64位服务器组件，VS主机进程，没有VS主机进程，或者这些东西的任何组合，都会出现同样的情况。

可能很重要：如果我使用VS.NET profiler （采样模式），则应用程序运行速度就像没有连接调试器一样。所以我不能那样诊断它。刚检查，仪表模式也快速运行。对于并发性分析模式，同样快速。

关键数据：

• 该应用程序使用相当繁重的多线程（标准线程池中有40个线程）。无论如何，创建线程都会很快发生，而且不是一个慢点。有许多锁，WaitHandle和Monitor模式
• 该应用程序完全没有例外。
• 该应用不会创建控制台输出。
• 该应用程序完全是托管代码。
• 该应用确实将磁盘上的几个文件映射到MemoryMappedFile：1x750MB和12x8MB以及一些较小的文件

测量表现：

• 两种情况下CPU使用率都很低;连接调试器时，CPU位于＆lt; 1％
• 两种情况下内存使用都很少;
可能是50或60MB
• 发生了大量的页面错误（参考MMF），但是当连接调试器时它们发生得更慢
• 如果没有使用VS主机进程，或者基本上“远程调试监视器”开始运行，则 使用相当数量的CPU并产生大量页面错误。但这不是问题发生的唯一时间
• 无论客户端如何运行，都会看到性能差异。唯一要更改的变量是服务器组件通过“从调试开始”和“从资源管理器启动”运行。

我的想法：

• 调试时WCF会变慢吗？
• MemoryMappedFiles在调试时会变慢吗？
• 使用了40个线程 - 调试速度慢？也许Monitors / locks通知调试器？线程调度变得奇怪/上下文切换非常罕见？
• 宇宙背景辐射赋予VS智慧和残忍的幽默感

所有人似乎都不太可能。

所以，我的问题：

1. 为什么会这样？
2. 如果＃1未知，我该如何诊断/发现？

Answer 1

异常会显着影响应用程序的性能。有两种类型的异常：第一次机会异常（使用try / catch块优雅处理的异常）和未处理的异常（最终会使应用程序崩溃）。

默认情况下，调试器不显示第一次机会异常，它只显示未处理的异常。默认情况下，它还仅显示代码中发生的异常。但是，即使它没有显示它们，它仍会处理它们，因此它的性能可能会受到影响（特别是在负载测试或大循环运行中）。

要在Visual Studio中启用第一次机会异常显示，请单击“调试|异常”以调用“异常”对话框，并在“公共语言运行时”部分中选中“抛出”（您可以更具体地选择第一次机会）你想看到的例外情况。）

要启用源自应用程序中任何位置的第一次机会异常显示，而不仅仅是代码，请单击“工具|选项|调试|常规”并禁用“启用我的代码”选项。

对于这些特定的“取证模式”情况，我还强烈建议启用.NET Framework源步进（它需要禁用“启用我的代码”）。了解正在发生的事情是非常有用的，有时只是看着调用堆栈是非常鼓舞人心的 - 特别是在宇宙辐射混合的情况下有用： - ）

两篇相关的有趣文章：

• How to debug crashes and hangs
• Configuring Visual Studio to Debug .NET Framework Source Code

Answer 2

Since this is one of the first results when googling for this issue I would like to add my problem solution here in the hopes of saving someone 2 hours of research like in my case.

My code slowed down from 30 seconds without debugger attached to 4 minutes with debugger. because I forgot to remove a conditional breakpoint. These seem to slow down execution tremendously, so watch out for those