I'm currently working on Implementing the idea I shared with you before, to use multiple threads to solve the image. It works REALLY well with the internal sexysolver, but I'm having a couple of issues with the external solvers. I am working with two algorithms I developed, one that solves in parallel threads with different scales and the other solvers with multiple depths based on your suggestion of the depth command. Both algorithms work perfectly on the internal solver, but for the external ones, I've had problems with each. I should be able to fix the issues in the next day or two I think. The issues are related to a couple of things. First, the external solvers require many temporary files in order to function. In order to get it to work efficiently, some of them should be shared, but others definitely should not. I'm working out which are which by experimenting. The second issue I have had relates to the options, I had to add the depth keyword for the depths algorithm, and I had to play around with the scaling parameters for the scales algorithm. It seems like it should be solvable in the next day or two.
As to how effective the parallel solves are, for images where we know the scale and position fairly well, the parallel solves actually hurts the solving time just a little. For some images that were solving in 0.2 seconds, they take 0.4 in parallel. For images where the scale and position are not known, however, the parallel solves are GREAT. For some images, the time was halved from 15 seconds to 8 seconds. For others it was cut by a factor of 10, from 10-15 seconds down to 0.9 seconds. And for others, I was never able to get them to solve before, and with this algorithm, I got them to solve in less than 10 seconds. So my thought is to have it turned off by default for now and I will make a profile that takes advantage of it. In the future once it is tested more, it might be good to have an if statement, so that if the scale and position are both provided, don't do it in parallel, but if one or both are left out, to go ahead and do it in parallel.
I hope that soon, I can get it to work on the external ones just as well. I am attaching a screenshot of an image that I had trouble solving before, but that solved with the new algorithm in just 4.3 seconds.