以下哪项任务并不总是花费一致的时间？

Question

我正在尝试使C#程序的加载部分更快。目前大约需要15秒才能加载。乍一看，加载部分所做的事情包括构造许多第三方UI组件、加载布局文件、xmls、DLL、资源文件、反射、等待WndProc……等。

我使用了一些非常简单的东西来查看某些部分所用的时间，即双精度断点，它保存了TimeSpan的总毫秒数，这是开头的DateTime.Now和结尾的DateTime.Now的差值。尝试几次会得到一些东西，比如11s 13s 12s 12s 7s 11s 12s 11s 7s 13s 7s。(通常为12秒，但有时为7秒)

如果我添加SuspendLayout，BeginUpdate就像地狱一样；在反射中调用一次而不是多次；减少一些冗余的计算冗余。时间如3s 4s 3s 3s 3s 10s 4s 4s 3s 4s 10s 10s 10s...(通常为4秒，但有时为10秒)

在这两种情况下，时间都不一致，但更像是双峰分布？这真的让我不确定我对代码的修正是否真的让它变得更快了。所以我想知道是什么导致了这样的结果。调试模式？"C#必须在第一次运行时编译/解释代码，但接下来的时间会更快“的事情？WndProc消息的等待？反省？PropertyInfo？Reflection.Assembly？加载文件？XML？DLL？资源文件？UI布局？(该部分肯定没有互联网/网络/数据库访问)

谢谢。

Answer 1

正如您已经发现的，通过在调试器中停止来分析并不是获取时间的可靠方法。

通过将时间写入日志来分析性能很好，但是既然可以在dotTrace中启动程序，为什么还要手工完成所有这些工作呢？(免费试用，全功能)。

当你无法访问分析器时，另一件事是我所说的二进制方法--看看代码中发生了什么，并尝试通过使用注释禁用大约一半的代码。注意对运行时间的影响。如果它看起来很重要，对一半重复这个过程，然后递归地重复，直到你缩小到最重要的部分。困难在于模拟缺失代码的副作用，以便其余代码仍然可以工作，因此这仍然比使用调试器更困难，但可以比添加大量手动时间日志记录更快，因为二进制方法允许您在对数时间内将重点放在最慢的位置。

Raymond Chen的建议在这里很好。当人们问他“我怎样才能让我的应用程序启动得更快？”he says "Do less stuff."

(并且总是分析发布构建-分析调试构建通常是徒劳无益的)。

Answer 2

对其进行分析。你可以免费使用eqatec

Answer 3

最好的办法就是通过分析器运行你的应用程序，看看瓶颈是什么。我个人也用过dotTrace，你可以在网上找到很多其他的。

调试模式关闭了许多JIT优化，因此应用程序的运行速度将比发布版本慢得多。无论采用哪种模式，JITting都必须发生，所以我认为这是一个重要因素。从磁盘读取文件的时间可以根据操作系统的缓存机制以及您是进行冷启动还是热启动而有所不同。

如果你必须使用计时器来分析，我建议你大量重复这个实验并取平均值。