【发布时间】：2012-06-15 04:51:13
【问题描述】：
我正在测试几种不同的算法（用于解决 16x16 数独） 相互对抗，使用 timeit 模块测量它们的性能。 但是，似乎只有第一次 timeit.repeat() 迭代是 实际计算，因为其他迭代变得更快。 使用 t.repeat(repeat=10, number=1) 测试单个算法如下 结果得到：
[+] ......的结果：solve1（函数 1/1）
[+] 最快............：0.00003099
[+] 最慢............：32.38717794
[+] 平均值*.........：0.00003335（计算平均值，不含最小值/最大值）
10 个结果中的第一个总是需要更长的时间才能完成， 这似乎只能通过迭代 2 到 10 的事实来解释 timeit.repeat() 循环以某种方式使用循环先前的缓存结果 迭代。在 for 循环中实际使用 timeit.repeat() 进行比较时 几种算法相互对抗，再次看起来解决方案 到拼图只计算一次：
[+] ......的结果：solve1（函数 1/3）
[+] 最快............：0.00003099
[+] 最慢............：16.33443809
[+] 平均值*.........：0.00003263（计算平均值，不含最小值/最大值）
[+] ......的结果：solve2（函数 2/3）
[+] 最快............：0.00365305
[+] 最慢............：0.02915907
[+] 平均值*.........：0.00647599（计算平均值，不含最小值/最大值）
[+] ......的结果：solve3（函数 3/3）
[+] 最快............：0.00659299
[+] 最慢............：0.02440906
[+] 平均值*.........：0.00717765（计算平均值，不含最小值/最大值）
真正奇怪的是相对速度（相对于彼此） 的算法在整个测量过程中是一致的，这表明 所有算法都在计算自己的结果。这种性能的极端提升是否是由于大部分中间结果（得到 在计算第一个解决方案时）仍然在某种缓存中，由 蟒蛇进程？
任何帮助/见解将不胜感激。
【问题讨论】：
-
由于您没有显示代码，我的猜测是您正在缓存部分结果并且不知道它。您的实现也有可能非常占用内存，因此第一次迭代支付了解释器请求后续迭代重用的系统资源的开销。
-
没有代码，这个问题是无法回答的。