我正在测试几种不同的算法（用于解决16x16 sudokus） 彼此相对，使用timeit模块测量它们的性能。 但是，似乎只有timeit.repeat（）迭代中的第一个迭代 实际计算，因为其他迭代得到更快。 使用t.repeat（repeat = 10，number = 1）测试单个算法如下 结果得到了：
[+] ......的结果：solve1（函数1/1）
[+]最快..........：0.00003099
[+]最慢..........：32.38717794
[+]平均值* .........：0.00003335（平均值计算无最小/最大值）
十分之一的结果总是需要更长的时间才能完成， 这似乎只能通过迭代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（平均计算无最小/最大值）
真正奇怪的是相对速度（相对于彼此） 这些算法在整个测量过程中是一致的，这表明 所有算法都在计算自己的结果。由于大部分中间结果（获得），这种性能的极端提高是否会增加 当计算第一个解决方案时）仍然在某种缓存中，由...保留 python进程？
非常感谢任何帮助/见解。
答案 0 :(得分：1)
我认为内存分配是个问题。
python解释器本身拥有一个内存池，它从没有（或很少？）内存池开始。在第一次运行程序之后，会分配大量内存（从系统中）和释放（到池中），然后以下运行从池中获取内存，这比从系统中查询内存要快得多。
但这只有在你的算法消耗大量内存时才有意义。