我有一个Sudoku解决算法,我的目标是尽可能快地做.要测试这个算法,我运行它多次并计算平均值.注意到一些奇怪的数字后,我决定打印所有的时间,得到这个结果：
Execution Time : 4.257746 ms (#1) Execution Time : 7.610686 ms (#2) Execution Time : 6.277609 ms (#3) Execution Time : 7.595707 ms (#4) Execution Time : 7.610131 ms (#5) Execution Time : 5.011104 ms (#6) Execution Time : 3.970937 ms (#7) Execution Time : 3.923783 ms (#8) Execution Time : 4.070238 ms (#9) Execution Time : 4.765347 ms (#10) Execution Time : 0.818264 ms (#11) Execution Time : 0.620216 ms (#12) Execution Time : 0.679021 ms (#13) Execution Time : 0.643516 ms (#14) Execution Time : 0.718408 ms (#15) Execution Time : 0.744481 ms (#16) Execution Time : 0.760569 ms (#17) Execution Time : 0.80384 ms (#18) Execution Time : 0.75946 ms (#19) Execution Time : 0.802176 ms (#20) Execution Time : 66.032508 ms : average = 3.3016254000000003
经过10到15次执行(随机变化),算法的性能大幅提高.如果我跑几百次,最终将稳定在0.3ms左右.请注意,我在JIT的这个循环之前运行一次算法来做它的事情.
此外,如果我让线程休眠2秒钟,然后再运行我的循环,我的所有时间都在1ms(/ – 0.2).
此外,如果我在循环之前解决了一个通用的Sudoku(一个1-9对角线的网格)大约500次,我的所有时间都在0.3ms左右(/ – 0.02).
每个解决都是一样的.所有值都被重置.
所以我的问题是多重的：
– 为什么每个解决时间改善后连续解决？
– 为什么10-15之后解决时间突然下降？
解决方法
这是因为
JIT在JVM对该方法进行一定次数的频繁调用之后编译该方法.在实践中,方法在第一次被调用时不会被编译.对于每个方法,JVM维护一个调用计数,每次调用时都会增加调用计数. JVM解释一个方法,直到其调用计数超过JIT编译阈值.当调用计数达到阈值时,JIT将编译和优化字节码,以便在下一次由JVM调用时运行更快.因此,在您的情况下,每10到15次(随机)执行后,算法的性能将大大提高.