Start simple and optimize. Check apache commons collections or google for
LRU maps. You probably will only find non-thread-safe LRU maps, but that is
ok for a start. Use a java synchronized map wrapper on it. Then check how
much performance you gained using this compared to the current performance
of recompiling every time. If the optimization is good enough, go ahead am
implement it.
If it is not, then we look for alternatives, including making the LRU map
thread safe.
On this topic, Drools is licensed with Apache v2 license. So, if you are
using any external code, it must have a compatible license. Apache commons
is obviously fine.
Thanks,
Edson
2009/5/5 Jared Davis <sunray(a)davisprogramming.com>
Edson Tirelli <tirelli <at> post.com> writes:
>
>
> Jared, Your idea is actually interesting. Although, we would need to
take
care of a few edge scenarios:* The actual evaluator instance is supposed to
be a
"fly weight" implementation, and as so, it might be used by multiple
threads.
So, first thing, the cache map implementation must be thread safe. * We had
problems in the past when using static caches like that in JEE/Spring/OSGi
environments where you have multiple modules being loaded by different
classloaders etc. So, I think best would be to have a non-static map for
each:
the StringMatchesEvaluator and the StringNotMatchesEvaluator inner
classes.* We
need a way to clean up the cache for no-longer used expressions. Easiest
way
would probably be to use an LRU map as cache. The size of the cache would
probably have to be a configuration on the KnowledgeBaseConfiguration, with
a
given default value. This would avoid memory leaks. Wanna try providing
a
patch for that? Thanks, Edson
2009/5/4 Jared Davis <sunray <at>
davisprogramming.com>I need some help placing a cache of compiled regular
expressions using the
> MatchesEvaluatorsDefinition as a starting point.
> Just for a test I placed a static map in the class:
> static Map<String,Pattern> uglyHack = new HashMap<String,Pattern>();
> Then in each of the evaluators I have different versions of:
> Pattern p = uglyHack.get(value2);
> if (p == null ) {
> p = Pattern.compile(value2);
> uglyHack.put(value2, p);
> }
> Matcher m = p.matcher(value1);
> return m.matches();
> instead of
> return value1.matches( value2 );
> The time elapsed to inserting objects into the workspace has been cut in
half.
> .4 seconds -> .2
> Has someone already done this "optimization?" Where should the cache be
stored?
> _______________________________________________
<snip>
Edson,
One persons memory leak is another's optimization.<g>
I'll give it a shot. Is there a drools preferred thread safe LRUCache
implementation? Seems like hours/days could be spent on the cache
algorithm.
Jared
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @
www.jboss.com