The Google ROADEF research competition ended 2 weeks ago and I had too little time to submit an entry with Drools Planner .

However, I 've done a few quick tries on the B instances the last 2 weekends to test the just-in-time selectors :

• 300 seconds single-threaded on JDK 6 on my 2 year old computer
• Entity tabu search with size 7, minimalAcceptedSelection 2000
• With the new just-in-time selectors enabled.

Update: I 've updated the results on 1-JUL-2012 to include the memory footprint fix.



Here are Planner's results on the B instances, which are notorious for their large problem scale:

Instance	Hard Score	Soft score	Better than original
B1	0	3 747 407 470	51 %
B2	0	1 059 414 398	80 %
B3	0	163 774 536	97 %
B4	0	4 677 922 316	49 %
B5	0	923 842 568	93 %
B6	0	9 525 882 691	25 %
B7	0	15 313 722 822	60 %
B8	0	1 214 588 654	91 %
B9	0	15 885 640 056	32 %
B10	0	18 814 086 531	55 %
Average			63 %

Note that the original solution is not some random solution, but already a feasible solution. This means the machine resource utilization would be 63% better on average by using Drools Planner.



All instances were solved in their entirety: I didn't need to result to partitioning like some of the other contestants to be able to solve them.

All instances require 1 GB memory or less, but the results above are done with 2 GB memory, because the biggest instance (B10) gives better results with a heap slightly bigger then 1 GB.



Note that the solver configuration hasn't been thoroughly tweaked. Now, with the end of the competition, that the other contestants are also opening their ideas (and hopefully their code), it will be interesting to see what we can learn from each other. I 've already had some conversations with the excellent Kaho team last week and I 'll be experimenting with some of their suggestions.