Currently only has effect where the evaluator is called MANY times, e.g. at depth 7 for [r1b2rk1/ppq2ppp/3bpn2/3pP3/8/2PB2B1/PP1N1PPP/R2QK2R b KQ - 0 11]:
test_perf_base 397709282 function calls (396717202 primitive calls) in 132.203 seconds
test_perf_delta_pruning 352045446 function calls (351229716 primitive calls) in 116.375 seconds
test_perf_combined 76599863 function calls (76421728 primitive calls) in 25.200 seconds - pretty amazing!
Otherwise it keeps the runtime about the same, though evaluator is called less (this means the extra time to calculate the piece type of captured pieces becomes the bottleneck, I think): [r1b2rk1/ppqn1pbp/6p1/3pp3/7B/2PB1N2/PP3PPP/R2QR1K1 w - - 0 16], depth 4:
Currently only has effect where the evaluator is called MANY times, e.g. at depth 7 for [r1b2rk1/ppq2ppp/3bpn2/3pP3/8/2PB2B1/PP1N1PPP/R2QK2R b KQ - 0 11]:
Otherwise it keeps the runtime about the same, though evaluator is called less (this means the extra time to calculate the piece type of captured pieces becomes the bottleneck, I think): [r1b2rk1/ppqn1pbp/6p1/3pp3/7B/2PB1N2/PP3PPP/R2QR1K1 w - - 0 16], depth 4: