<br> 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. <br>
<br> If it is not, then we look for alternatives, including making the LRU map thread safe. <br><br> 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.<br>
<br> Thanks,<br> Edson<br><br> <br><br><div class="gmail_quote">2009/5/5 Jared Davis <span dir="ltr"><<a href="mailto:sunray@davisprogramming.com">sunray@davisprogramming.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Edson Tirelli <tirelli <at> <a href="http://post.com" target="_blank">post.com</a>> writes:<br>
<br>
><br>
><br>
> Jared, Your idea is actually interesting. Although, we would need to take<br>
care of a few edge scenarios:* The actual evaluator instance is supposed to be a<br>
"fly weight" implementation, and as so, it might be used by multiple threads.<br>
So, first thing, the cache map implementation must be thread safe. * We had<br>
problems in the past when using static caches like that in JEE/Spring/OSGi<br>
environments where you have multiple modules being loaded by different<br>
classloaders etc. So, I think best would be to have a non-static map for each:<br>
the StringMatchesEvaluator and the StringNotMatchesEvaluator inner classes.* We<br>
need a way to clean up the cache for no-longer used expressions. Easiest way<br>
would probably be to use an LRU map as cache. The size of the cache would<br>
probably have to be a configuration on the KnowledgeBaseConfiguration, with a<br>
given default value. This would avoid memory leaks. Wanna try providing a<br>
patch for that? Thanks, Edson<br>
<br>
</div>2009/5/4 Jared Davis <sunray <at><br>
<div class="im"><a href="http://davisprogramming.com" target="_blank">davisprogramming.com</a>>I need some help placing a cache of compiled regular<br>
expressions using the<br>
> MatchesEvaluatorsDefinition as a starting point.<br>
> Just for a test I placed a static map in the class:<br>
> static Map<String,Pattern> uglyHack = new HashMap<String,Pattern>();<br>
> Then in each of the evaluators I have different versions of:<br>
> Pattern p = uglyHack.get(value2);<br>
> if (p == null ) {<br>
> p = Pattern.compile(value2);<br>
> uglyHack.put(value2, p);<br>
> }<br>
> Matcher m = p.matcher(value1);<br>
> return m.matches();<br>
> instead of<br>
> return value1.matches( value2 );<br>
> The time elapsed to inserting objects into the workspace has been cut in half.<br>
> .4 seconds -> .2<br>
> Has someone already done this "optimization?" Where should the cache be stored?<br>
> _______________________________________________<br>
<br>
</div><snip><br>
<br>
Edson,<br>
<br>
One persons memory leak is another's optimization.<g><br>
<br>
I'll give it a shot. Is there a drools preferred thread safe LRUCache<br>
implementation? Seems like hours/days could be spent on the cache algorithm.<br>
<font color="#888888"><br>
Jared<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>