hgm wrote: It doesn't matter how long it takes to convert. You don't search all the way to conversion, you only search until you enter the EGT. Even in a position with 4 defenders each this is often a matter of moving an Elephant away from e2, pulling back an Advisor from e1, stepping the King forward, and moving the Rook to the enemy half. That is only 9 ply. After that the EGT probe gives you the DTM. The static evaluation for KR*K* (used when there is no EGT hit) has a special term that encourages exposing the strong-side King, overruling its normal tendency to savely hide it behind defenders. This makes the search usually go for the most efficient move sequence straight away.
It is always OK if you are happy with your EGT
For me, I am not a fan of searching for endgames. As I have written some endgames require over 30 (not only 9 plies) correct moves for their first captures. My testing program gave up on that after searching a long time, say 1 h on my laptop (Intel core 7 2.5 G). Hope yours could do much better.
BTW, I have added few positions at the end of this post. Could you try with your EGT? If your program can solve them correctly, I will add some more difficult (I need time to search from my database).
A full KR*K* EGT is pretty big: my indexing scheme uses 119 'Palace states' and 29 'Elephant states', for a total of 3,451 defender constellations. (This includes 16*7 = 112 'broken positions' where an Elephant collides with a King, but this is too small a fraction to bother.) If I would also have that number of constellations for the KEEAA of the attacking side I would alread be at 11M (ignoring a few more broken positions because of King facing). Adding a Rook that can go anywhere then gives 1G positions (2G if you do both sides to move). Uncompressed that would be barely feasible on a machine with 4G RAM (which is still pretty common). And now try it for KHH*K*, where the confinement of the Horses to the enemy half is less perfect than with R, but still works pretty well. This would contain 90G positions. With my scheme K"H'H'K* (where H' indicates confinement to enemy half, and K" confinement to the back rank) only takes 10.5M positions. Because of the sizes the choice is often not between having full KX*K* or partial K"X'K* for everything, but between having K"X'K* for many X and having nothing at all for most X.
It seems all your sizes are a bit strange and different (larger) from mine. I use the work of Fang & Hsu (Construction of Chinese Chess Endgame databases by Retrograde Analysis).
There are totally 3339 combinations of defenders. All tables of an one-but-not-pawn-attacking-piece (say KR*K*) take only 550 MB for one side or 1100 MB (uncompressed) for 2 sides.
Total of all tables of HH (KHH*K*) is 23 GB (uncompressed) for one side.
All tables of two-attacking-pieces (CC, CH, CP, HH, HP, PP) but no Rook (since Rook + any piece is mostly a sure win) take about 170 GB for one side in uncompressed format.
Some positions for testing EGT: