Very large memory usage with some 4x4 seeds

[Nogesma]

Using a seed like 67ff4ac6407c3ee6343e4d346f7cf831087590bdce7ef4e5af7cbdbc5ecf1497 makes the phase2 solver try to allocate a table of 17 GiB.

...
[Search][Depth Depth(10)] Starting search…
[Search][Depth Depth(10)] 176_326_682 recursive calls (21.398191611s) (8_240_260 calls/s)
----------------
[Prune table] Increasing hash prune table size to 17_179_869_184 entries…
[Prune table][Depth Depth(1)] 116 recursive calls (31.962µs) (3_629_309 calls/s)
[Prune table] Population is 34 entries (≈0% of 17_179_869_184 slots, ≈29% of latest depth recursive calls).
[Prune table][Depth Depth(2)] 892 recursive calls (155.333µs) (5_742_501 calls/s)
[Prune table] Population is 228 entries (≈0% of 17_179_869_184 slots, ≈26% of latest depth recursive calls).
[Prune table][Depth Depth(3)] 7_900 recursive calls (1.130164ms) (6_990_135 calls/s)
[Prune table] Population is 1_944 entries (≈0% of 17_179_869_184 slots, ≈25% of latest depth recursive calls).
[Prune table][Depth Depth(4)] 73_140 recursive calls (9.172568ms) (7_973_775 calls/s)
[Prune table] Population is 14_286 entries (≈0% of 17_179_869_184 slots, ≈20% of latest depth recursive calls).
[Prune table][Depth Depth(5)] 694_140 recursive calls (100.357875ms) (6_916_647 calls/s)
[Prune table] Population is 87_427 entries (≈0% of 17_179_869_184 slots, ≈13% of latest depth recursive calls).
[Search][Depth Depth(11)] Starting search…
...

Would it be possible to add an option to cap the size of all tables in the library? Or maybe make the default HashPruneTableSizeBounds have a capped size?

My server only has 2 GiB of ram, I don't really care about how much time it takes to generate, but at the moment the process gets killed randomly if a scramble allocates a large prune table.

[lgarron]

My server only has 2 GiB of ram, I don't really care about how much time it takes to generate, but at the moment the process gets killed randomly if a scramble allocates a large prune table.

Hmm, I certainly wouldn't recommend using twips for 4×4×4 for that case, but if you really want we can try to add a RAM limit and see if it can still find solutions. I think that would best be done using a debug API call, since it should not be a permanent issue.

[Nogesma]

I really only need to generate 10 4x4x4 scrambles per day, so I'm fine if it takes a bit more time than needed.

From what I tested it seems like most of the time, only around 87k entries are used, and the large size is only needed to avoid collisions if I'm not mistaken, so I'm not sure why more than something like 256MB would be needed. It also doesn't seem to really affect performance.

A debug API call works fine for me, I'm also fine with using the git version of twips so don't feel rushed to release a new version.