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