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

[Jared Davis]

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