[rules-users] Re: Help with MatchesEvaluatorsDefinition that caches compiled regular expression patterns

[Edson Tirelli]

   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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090505/e92d245e/attachment.html