Development has stalled.
It is far too slow.
It works perfectly for toy examples, but bogs down in the real world.
You have worked hard to make it faster. Each speed-up works, for the toy examples. But it never translates to significant improvement on real problems.
Even worse, every speed-up has made what was nice, neat software into a complicated bug-ridden mess.
This behaviour is typical of problems where you have to examine all possible combinations.
If it's all combinations two at a time, the time taken is proportional to the square of the number of items you have to compare. That is, if you double the number of items, the time taken is four times as long.
If it's all combinations three at a time, it's proportional to the cube of the number of items; double the number of items and the time goes up eight times.
The worst case is that where you have to compare each item against all combinations of the other items. Here, if you already have n items, adding one more item makes it take n times as long. Or, roughly speaking, every new item doubles the time to solve the problem.
I can apply many different techniques for reducing the number of combinations. Sorting the items before making the combinations often helps. Where you must insert the processed items back for further combinations, a priority queue implemented as a heap can work wonders.
For really intractable problems there is usually a fast way of getting pretty near the right answer. Would a close approximation satisfy your requirements?
I have solved many of these sort of problems, using the above approaches and also by applying techniques from one area of software engineering to an entirely different area.
