Op 10-04-12 19:00, Reinis schreef: > Thank you for all the tips. In the mean time I was able to locate the source > of serious performance "killer". These 3 rules: > > http://nopaste.info/3f89c43eee_nl.html The use of "contains()" can break incremental score calculation, which causes the score count to go down a lot. An alternative I sometimes do to avoid that, is to insert the elements of those contains list into the working memory too and directly LHS match on those. > I tried to reorganize and re-optimize them at least 10 times to no avail. I'd > appreciate, if anyone could suggest me how to change them to get the > performance up. > > Until now I have tried: > - reducing variable bindings (e.g. resource == $resource to resource == > $maxLoad.resource) > - moving accumulate from constraint rules to "insert momentary load" > - joining sum for TUs and Picks in one accumulate > - and number of other less useful changes > > still, if I add these rules the calculate count goes down from approx 5300 to > 2000 per second which is more than a half. Since it's higher then 1000 (for your biggest dataset I presume), I wouldn't worry about it too much. If you do want to squeeze out everything and are willing put up with a high maintenance and less flexibility cost for that, see this blog: http://blog.athico.com/2012/04/plain-old-java-score-calculation-in.html
Turn on the statistic BEST_SOLUTION_CHANGED, grab the CSV file and make a graph of time vs your hard score. That graph will show you if it's stuck anywhere for a long time. If that graph is an almost straight line, then your score calculation is too slow indeed. > Thanks and kind regards, > Reinis > > On 04/06/2012 01:50 PM, Geoffrey De Smet wrote: > >> I just realized that the graph only prints out values (the soft score) >> of the hard score = 0. >> Since you don't reach feasibility early on, the graph will be zero. >> Try to tmp hack it to get the graph by disabling soft constraints and >> putting the hard constraints values in the soft score. >> >> With kind regards, >> Geoffrey De Smet >> >> >> Op 06-04-12 13:46, Geoffrey De Smet schreef: >>> 32 hours, that is very long, especially if you're talking about >>> feasibility. >>> Feasibility much be attained within seconds or maybe 2 minutes. >>> >>> So either your problem is very, very constrained (unlikely) >>> or there is much room for optimization. >>> >>> Run the Benchmarker and enable the statistic BEST_SOLUTION_CHANGED. >>> Verify that you have a good graph, and not a bad graph. See this issue >>> to see the difference: >>> https://issues.jboss.org/browse/JBRULES-3451 >>> >>> >>> Op 06-04-12 13:33, dro...@orbit-x.de schreef: >>>> Thank you, Geoffrey! >>>> This is the answer I was hoping for and it confirms my >>>> understanding of this problem. >>>> Indeed it looks like it will be a standard implementation (since it >>>> is (A) and (C)). >>>> The reason I was willing to ask the community is that current >>>> (non-optimizied prototype solution) takes approx. 32 hours to >>>> complete. But I am pretty sure that optimized move factory, rule >>>> definitions and engine configuration will move the completion time >>>> down to expected 6 hours. >>>> -----Original-Nachricht----- >>>>> Von: "Geoffrey De Smet"<ge0ffrey.s...@gmail.com> >>>>> An: rules-users@lists.jboss.org >>>>> Datum: 05-04-2012 11:34 >>>>> Betreff: Re: [rules-users] [Drools Planner] Proof-of-Concept >>>>> Stock-planning System >>>>> >>>>> Op 03-04-12 23:10, Reinis schreef: >>>>>> Hello, >>>>>> >>>>>> I want to ask you, guys, if you could guess if it is possible or >>>>>> probable to build such a System with Drools Planner: >>>>>> >>>>>> The system shall plan the best time where the transport unit (TU) >>>>>> has to >>>>>> be input into stock system to reach set delivery deadlines, >>>>>> utilization >>>>>> of resources and load balancing of bottle necks (all expressed as >>>>>> rules). >>>>>> >>>>>> Most of things (resource capacity, route within the stock system, >>>>>> etc.) >>>>>> are given and constant facts. Actually there is only one planning >>>>>> variable - time interval of a transport unit characterizing retention >>>>>> period within a given Resource. Like this: >>>>>> >>>>>> TU#1 is in Resource #A from 11:00 till 11:30<- the optimal interval >>>>>> has >>>>>> to be planned >>>>> Is the value range something like this: >>>>> (A) >>>>> - 10:00 till 10:30 >>>>> - 10:30 till 11:00 >>>>> - 11:00 till 11:30 >>>>> - 11:30 till 12:00 >>>>> Or like this? >>>>> (B) >>>>> - 11:00 till 11:15 >>>>> - 11:01 till 11:16 >>>>> - 11:02 till 11:17 >>>>> - 11:03 till 11:18 >>>>> ... >>>>> From reading further, I presume (A). >>>>> >>>>>> TU#1 is in Resource #B from 11:45 till 12:00<- the optimal interval >>>>>> has >>>>>> to be planned >>>>>> >>>>>> TU#1 is in Resource #C from 12:30 till 13:00<- the optimal interval >>>>>> has >>>>>> to be planned >>>>>> >>>>>> I have following problem size and constraints: >>>>>> - TUs per day: 160'000 >>>>>> - Amount of resources a TU travel through: 3 >>>>> Do the TU need to go through it's 3 resources in a specific order? >>>>> (C) No >>>>> (D) Yes >>>>> I presume it can not go through 2 resources at the same time. >>>>>> - Average smallest time interval: 15 Min >>>>>> - Planning period: 09:00 - 16:00 = 8 hours = 32 intervals >>>>>> - Initial planning window: 4-6 hours >>>>>> - continuous planning multiple batch execution time during the day >>>>>> after >>>>>> addition and/or retraction of number of TUs: 20 minutes >>>>> (E) This is repeated planning (see documentation manual if you haven't >>>>> already). >>>>>> So the problem size would be(?): >>>>>> (TUs * resources) ^ intervals = (160'000 * 3) ^ 32 = 6.305500958×10¹⁸¹ >>>>> That's not a big search space. In some examples I 've seen 10^6800. >>>>> Of course, the search space isn't the only metric to take into account >>>>> (but I haven't found a good way to measure the other metrics, >>>>> such as how-constrained-is-the-problem, how-big-is-the-snowball-effect, >>>>> ...). >>>>>> I know there is no one answer to this question. I would like only >>>>>> to get >>>>>> your feeling on this problem. Would you take on solving this sort of >>>>>> problem with drools planner? >>>>> Definitely :) >>>>> If it's (A) and (C), it should be an easy, standard implementation. >>>>> If it's (B) and (D), then it becomes interesting :) >>>>> >>>>> The only part I expect some rough edges is (E). >>>>> I suspect you'll be asking for build-in support for "planning entity >>>>> locking" to do your continuous planning easily. >>>>> https://issues.jboss.org/browse/JBRULES-3359 >>>>> It's a PITA to do that yourself for now. >>>>>> thanks and br >>>>>> Reinis >>>>> -- >>>>> With kind regards, >>>>> Geoffrey De Smet >>>> >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users -- With kind regards, Geoffrey De Smet _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users