matchUntilHalt() uses a lot of CPU? #68

devijvers opened this Issue Aug 31, 2013 · 3 comments

2 participants


I've noticed that both in Node.js and in the browser matchUntilHalt() uses a lot of CPU. Is this observation correct and if so how can it be alleviated?


I've investigated this further. My rules aren't finished yet. There's one rule that modifies a fact for which there is no matching rule. When this last rule is invoked and the fact is modified Nools peaks at 100% with matchUntilHalt. To be clear, there is no halt() call anywhere in my rules.

When I apply this modification - and I don't modify my rules - the peak CPU problem goes away:

var finished = true;
var doMatch = function doMatch() {
  if (finished) {
    finished = false;
    console.log("restarting ...");
    session.match(function(err) {
      finished = true;
      console.log("ending ...");
      if (err) {
        throw err;
var modify_fn = session.modify;
session.modify = function modify(o, cb) {, o, cb);


/*session.matchUntilHalt(function(err) {
  if (err) {
@doug-martin doug-martin was assigned Sep 1, 2013
C2FO member

Yep so the way matchUntilHalt works currently is naive in that it just essentially does a async loop using setImmediate for each loop causing the CPU usage to be high. I think what you have above could be adapted to monitor any assert, retract, or modify to do the looping.


I agree. assert/retract/modify should be a signal that match needs to restart.

There's also an infinite loop - also with the regular match when there is more than one rule that applies. I think the same applies here: there's no point for match to keep verifying until assert/retract/modify have been fired.

Come to think of it, I guess I could have used the emitted events as well.

@doug-martin doug-martin added a commit to doug-martin/nools that referenced this issue Sep 24, 2013
@doug-martin doug-martin v0.1.13
* Fixed issue #68 where `matchUntilHalt` uses a lot of CPU
* Fixed issue #45, now compiled rules support `or` constraint with more than 2 inner constraints.
* Added new feature to address #76, now you can use `deleteFlows` to dispose all flows, or use `hasFlow` to check if a flow is already registred with `nools`.
@doug-martin doug-martin referenced this issue Sep 24, 2013

v0.1.13 #77

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment