Long runtime for a reduced CH2 puzzle

[DougCube]

I am seeing very slow performance in a case. I suspect it is not leveraging some optimization. Perhaps it is not properly pruning moves that only swap/cycle indistinquishable pieces. Moves that don't alter the current position due to only cycling sets of indistinguishable pieces (including cases of multiple disjoint sets), should be removed from consideration. I'm not convinced it's doing this sort of optimization currently. There are puzzles with lots of 2-cycle moves which can probably benefit greatly from this sort of optimization -- or perhaps it's the high number of "canonical move states" (900 in this case) where it benefits.

Specifically, I have in the following testcase, a CH2 (Corner Helicopter 2x2) with piece types TIPs and WINGs removed in both the definition and scramble state, then partition the 24 MIDGE pieces into just 2 groups: those 8 belonging on the M-slice and those 16 that do not. All it is solving is the underlying 2x2x2 (with locked DBL corner using only <U,F,R> moves) and some edge-turns that swap two midges.

> time ./build/bin/twsearch --quiet -c 1 stage1_mod.tws rand_0_stg1_in.scr
Trying to allocate 8589934656
 U' F R' U2 R U2 UB UF BL FL U' R2 F2 R' DB R2 U'
Found 1 solution max depth 17 lookups 4730388790 in 22.5919 rate 209.384

real    0m24.888s
user    8m34.246s
sys     0m19.387s

It really should not take nearly 25 seconds (on a very modern, high-spec computer) when dealing with the low branching-factors involved in this search and with a solution at depth 17. I expected it take less than 1 second to find because the tool solves a 2x2x2 in under 1 ms.

ch2_testcase2.tar.gz

[DougCube]

Also, moves that touch already solved midge pieces (solved relative to its corner) don't need to happen unless all of them are solved except for neeing a 3-cycle of midge around the same corner, in which case it is necessary to borrow a solved slot to make the cycle happen.