Well, you never know it performs until you try. :) See attached project. $ java -jar target/DroolsMapTest-1.0.jar eval.drl {bar=0} {foo=1000000} Time: 6607ms
$ java -jar target/DroolsMapTest-1.0.jar mvel.drl {bar=0} {foo=1000000} Time: 13077ms So eval ended up being 2x as fast, at least for this micro benchmark. I guess the fact that the "this['foo']" expressions are not indexed, plus the fact that they're interpreted mvel, doubles up. Stick with the eval. --- On Thu, 8/13/09, André Thieme <address.good.until.2009.dec...@justmail.de> wrote: > From: André Thieme <address.good.until.2009.dec...@justmail.de> > Subject: Re: [rules-users] Drools and Clojure > To: "Rules Users List" <rules-users@lists.jboss.org> > Date: Thursday, August 13, 2009, 6:29 PM > With what have you been wrong Greg? > I understood Marks reply in such a way that the mvel > dialect allows to > use Maps without eval. But this is just syntactic sugar. > When compiled > or interpreted (I don't know which of those Drools will do > with mvel > rules), this will get replaced with an eval under the > hood. > So, that means that still the optimizations can't be > applied. > Maybe the mvel rule is only interpreted, which would make > it even slower. > > For me it does not matter much which syntax will be my > target. > My Clojure lib will allow to write down rules in > s-expression > syntax, and it will compile them (compilation is also > available at > runtime) into any syntax Drools accepts. > Currently my target is the default syntax - that means I > will > produce strings that access Maps with eval. > > IF the mvel syntax will result in more performant code > because it > makes Drools handle it better without using eval under the > hood, then > sure, I can also compile into mvel syntax. > Although with that I still have the little problem to have > globals in > place of literals for Map lookups (see my other mail). > > > > Greg Barton schrieb: > > I was wrong. :). See Mark's later email. > > > > GreG > > > > On Aug 13, 2009, at 17:25, André Thieme > > <address.good.until.2009.dec...@justmail.de> > wrote: > > > > Greg Barton schrieb: > > There's no reason why a rete based system couldn't use > maps as first > > class objects, but Drools is heavily oriented towards > POJOS. Using > > eval in the way you have is pretty much the way to > go. > > > > Thanks for confirming that. > > For now I know that I am doing it right by using eval > and that this > > means that rules for typical Clojure objects will not > benefit from some > > of the optimizations Drools usually can apply. > > Maybe it will change in the future. > > > > > > As long as type information is accessible (both for > first class types > > and their members) you should be able to have the left > hand side of a > > rule (the conditions) be as it is now. > > > > I think that if Maps become 1st class objects there > could be a different > > Syntax, without using eval. > > > > > > If you lobby the devs hard enough and get others on > your side you may > > be able to convince them to go in that direction, but > I doubt it > > would be possible before version 6 or so, if that > early. (And I'm > > not even sure it's possible.) > > > > At this point it is mostly interesting for me to get > Drools working with > > Clojure together and concentrate on correctness. The > goal is that users > > of my lib can use do all typical things people do with > Drools without > > writing Java code. Everything, including the rules, > would be written in > > Clojure. > > But of course it would be very interesting if the devs > could indeed have > > Clojure in mind. I don't know how reusable the > existing code is, for > > using Maps without the need for eval and with having > the respective > > performance advantages. > > I understand that the looup of the value for a given > key can not be > > optimized away. On my hardware get() is limited to > "only" 1000 calls > > per msec and core. Reading a field from a POJO is > faster. > > If I understand it correctly then the "problem" with > eval is that it > > needs to be executed each time, and no clever caching > can be done. > > So, eliminating that by having Maps being 1st class is > what sounds > > interesting. > > When I refer to Maps and Clojure, then I talk about > Maps having only > > very few key/value pairs, just like POJOs, and being > immutable. > > This immutability may even be very helpful for > optimization. It is > > guaranteed that a given object will never change. > > > > I hope the devs will find it okay if I make some > concrete suggestions > > in the coming weeks. > > > > > > Sunny greetings, > > André > > > -- > Lisp is not dead. It’s just the URL that has changed: > http://clojure.org/ > _______________________________________________ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users >
DroolsMap.tar.gz
Description: GNU Zip compressed data
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users