[rules-users] Drools and Clojure

[Greg Barton]

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.14 at justmail.de> wrote:

> From: André Thieme <address.good.until.2009.dec.14 at justmail.de>
> Subject: Re: [rules-users] Drools and Clojure
> To: "Rules Users List" <rules-users at 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.14 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>


      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DroolsMap.tar.gz
Type: application/x-gzip
Size: 4178 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20090813/bd5c7ce7/attachment.gz