Getting to a point where I am performing integration testing with the new (6.4) version of the CLIPS engine. I have converted my 15+ year old C++ application to C# and kept the rules, facts, etc. the same just the interface into CLIPS has changed.
I noticed a speed difference in execution over v6.0 in general calling the engine once per process lifetime and more significant performance issues when calling CLIPS repeatedly during a single process lifetime.
I went from a sub-second turn around to 3-4 seconds for a single call.
Calling repeatedly there is a clear buildup of time for Reset to complete that appears to go exponential. Its as if something is accumulating in memory and each successive call to Reset takes longer. For example, my first call to Reset takes 20 miliseconds according to my log file entries which surround the call:
2018-10-18 08:07:26.713 Resetting CLIPS
2018-10-18 08:07:26.733 Reset CLIPS
After 80 successive calls (same workflow as original code) the delay has slowly built and now exceeds 20 seconds:
2018-10-18 08:33:55.329 Resetting CLIPS
2018-10-18 08:34:15.491 Reset CLIPS
From what I recall, Reset should be clearing any facts and get the engine ready for more work. The rules remain loaded just need the facts cleared.
Also, what is the difference between Reset and Clear? Does Clear remove facts and rules?
Haven't had a chance to debug through the code but will be starting that in a bit. Need to try to put my C hat back on.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Clear removes constructs (defrule, deftemplate, deffacts, ...) and all facts/instances. Reset removes all fact/instances and then processes deffacts/definstances.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hard to say without looking a specific case of the issue. Generally what I would do is compile the old and new code with profiling enabled to see where the performance issue lies.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Doing some preliminary profiling it looks like the time is coming from factmngr.c around the ResetFacts function which involves the RetractAllFacts -> Retract -> RetractDriver.
Things are definitely more complex over the v6 code.
Any hints or help?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those functions are also called by the 6.0 source code, so that doesn't shed much insight on the time differences between 6.0 and 6.4. Retracting the existing facts and reasserting the facts from deffacts is the most significant action performed by the reset, so it's not surprising that profiling would flag functions related to those actions. I'd try profiling both the 6.0 and 6.4 code to see what the time differences are within RetractDriver.
I also ran a benchmark program through hundreds of reset/run cycles and didn't see any significant changes in the amount of time it took to do a reset.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Getting to a point where I am performing integration testing with the new (6.4) version of the CLIPS engine. I have converted my 15+ year old C++ application to C# and kept the rules, facts, etc. the same just the interface into CLIPS has changed.
I noticed a speed difference in execution over v6.0 in general calling the engine once per process lifetime and more significant performance issues when calling CLIPS repeatedly during a single process lifetime.
I went from a sub-second turn around to 3-4 seconds for a single call.
Calling repeatedly there is a clear buildup of time for Reset to complete that appears to go exponential. Its as if something is accumulating in memory and each successive call to Reset takes longer. For example, my first call to Reset takes 20 miliseconds according to my log file entries which surround the call:
2018-10-18 08:07:26.713 Resetting CLIPS
2018-10-18 08:07:26.733 Reset CLIPS
After 80 successive calls (same workflow as original code) the delay has slowly built and now exceeds 20 seconds:
2018-10-18 08:33:55.329 Resetting CLIPS
2018-10-18 08:34:15.491 Reset CLIPS
From what I recall, Reset should be clearing any facts and get the engine ready for more work. The rules remain loaded just need the facts cleared.
Also, what is the difference between Reset and Clear? Does Clear remove facts and rules?
Haven't had a chance to debug through the code but will be starting that in a bit. Need to try to put my C hat back on.
Thanks!
Clear removes constructs (defrule, deftemplate, deffacts, ...) and all facts/instances. Reset removes all fact/instances and then processes deffacts/definstances.
Thanks Gary. Any thoughts on why there might be perfomance issues?
Hard to say without looking a specific case of the issue. Generally what I would do is compile the old and new code with profiling enabled to see where the performance issue lies.
Doing some preliminary profiling it looks like the time is coming from factmngr.c around the ResetFacts function which involves the RetractAllFacts -> Retract -> RetractDriver.
Things are definitely more complex over the v6 code.
Any hints or help?
Those functions are also called by the 6.0 source code, so that doesn't shed much insight on the time differences between 6.0 and 6.4. Retracting the existing facts and reasserting the facts from deffacts is the most significant action performed by the reset, so it's not surprising that profiling would flag functions related to those actions. I'd try profiling both the 6.0 and 6.4 code to see what the time differences are within RetractDriver.
I also ran a benchmark program through hundreds of reset/run cycles and didn't see any significant changes in the amount of time it took to do a reset.