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

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

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

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

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

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

关键数据：

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

测量性能：

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

我的想法：

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

所有人似乎都不太可能。

所以，我的问题：

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

Answer 1

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

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

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

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

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

两篇相关的有趣文章：

• 如何调试崩溃和挂起
• 配置Visual Studio以调试.NET Framework源代码

Answer 2

由于这是谷歌搜索这个问题的第一个结果之一，我想在这里添加我的问题解决方案，希望在我的情况下节省2个小时的研究。

我的代码从没有调试器的30秒减慢到使用调试器4分钟。 因为我忘了删除一个条件断点。 这些似乎极大地减缓了执行速度，因此请注意这些