[rules-users] Is there a faster way of doing this in Drools ?

[Vincent LEGENDRE]

> At this point I'm designing for the worst case i.e., I'm assuming the rules
> with change with every request. 

Keeping a cache will work for the worst case, but will work faster for "normal" (see below) cases.


> You can imagine the user changing these rules in a span of less than a
> minute. 

Well, no ... it is really hard to imagine that kind of frequence as a normal use over a long time.
For all systems I made, rules are stable for much more than that. When changing rules, you may change them every minutes (to test the outcomes, just like debuging a java code), but the objective is to produce something stable that will be used in a production environment ...
Changing rules every minutes or less in a production environment is definitely not a usual use-case ...
Why your rules should change every minute ? What is the system your are building ? 


> I understand that Drools is designed for cases when rules changes often. But
> can it support something like the one I described above where rules are
> changing at a much faster rate? 

You won't be able to speed up the compile time.
You can only act on the volume and organization of what you are compiling.
So, you can use cache (as said before), and may be you can also cut your rules in smaller packages and only recompile the package where some modifications take place (if it take really some mesureable time, it is likely also because you have plenty of rules to compile).
If you have a single package with few rules, compile time should not be a problem..


And a last thing : In your first post, you said :
>Based on the timing logs the code take majority (more than 80%) of time in
>only these two operations. Is there a way to make it faster ?
>
>KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();  
>kbuilder.add( org.drools.io.ResourceFactory.newByteArrayResource(getRule()),
>ResourceType.DRL);

You first have to make the distinction between KnowledgeBuilder compilation time (up to drools code, and you can't change anything, at least easyly), 
and your getRule() method (guess one of your custom code), with may be speeded up.
For instance, if you can't globally cut your compiled rules into smaller compiled packages, may be you can cut your big resulting DRL in smaller pieces, regenerating only what have changed ...