不同时刻的节目时间

发生这种情况是因为您的程序不是系统中唯一执行的实体，并且它并不总是立即获得所有资源。

由于这个原因，测量短时间的执行时间几乎没有什么价值，因为它们的变化非常明显。相反，如果您对更精确的时间测量感兴趣，您应该多次执行代码并计算所有运行的平均时间。

这只是一个想法，但这可能是因为内存使用的变化，后台应用程序的cpu使用在不同的时间变化。我的意思是，时差只会在

• 其他应用程序的内存使用情况
• cpu温度等物理条件。(时间变化真的很小)
• 和系统时钟。如果你做一个随机数生成或做任何操作，使用系统时钟在后台可能会产生这种变化。

希望这对你有帮助。欢呼。

这很简单。您使用一个不精确的计数器捕获系统时差，因为它占用了系统资源。有更多的程序与您的代码并行运行，有些程序优先于您的代码，导致线程临时(~20ms，取决于操作系统设置)挂起。即使在DOS中，也有代码与您的代码以准并行的方式运行，如果只有一个线程可能，那么您的代码在时间仍然滴答滴答的时候就会停滞(它由该代码控制)。

因为Windows不是一个实时操作系统。当您的程序执行时，可能会发生许多其他活动，并且cpu可以与其他正在运行的进程共享其周期。如果您的程序需要从物理设备(如磁盘(也包括数据库)和网络)读取数据，时间可能会发生更大的变化:这是因为物理资源可能忙于处理其他请求。如果存在page faults，那么你的应用程序需要从虚拟内存中读取页面，结果你会看到性能下降。由于您使用的是c#，在同一过程中，从第一次执行到其他执行的时间可以明显改变，因为代码是JITtted，即从中间代码编译为第一次看到的汇编，然后以汇编形式使用，这是显着更快。

这个假设是错误的。环境并不是一成不变的。程序的可用资源取决于许多因素。其他进程(如后台进程)对CPU和内存的使用情况。由于其他进程而占用的硬盘和/或网络。即使没有其他进程在运行，你的程序也会改变缓存的内部状态。

在"真实世界"的性能场景中，在"热身"后看到+/- 20%的波动并不罕见。即:连续测量10次作为"热身"，然后丢弃结果。测量10倍以上并收集结果。--> +/- 20%是很常见的。如果你不热身，你甚至可能看到由于"冷"缓存而产生的几个数量级的差异。

结论:你的程序非常小，使用很少的资源，它没有受益于持久缓存机制。