Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long Initialization Time #7

Closed
ab612 opened this issue Feb 22, 2018 · 6 comments
Closed

Long Initialization Time #7

ab612 opened this issue Feb 22, 2018 · 6 comments
Labels

Comments

@ab612
Copy link

ab612 commented Feb 22, 2018

Hello,

Thank you for developing this module. I was very excited when I first found it. Currently, I am trying to develop a forecasting tool using it. However, I've noticed that the creation and initial reset of a Knowledge Engine takes a lot of time. About 25 minuets for 10 fact classes and around 30 rules (on a very average computer). Is this to be expected? Please let me know. I have a feeling I'm missing something.

Thank you & Keep up the good work!
Madison S

@nilp0inter
Copy link
Contributor

Hi,

this is something unusual. We currently have pyknow in production with several thousand rules and we've never seen such a long initialization time. Are you using the stable version published in PyPI?

Could you maybe share some example code for me to test?

Thank you for your support!
Roberto

@ab612
Copy link
Author

ab612 commented Feb 27, 2018

Hello Roberto,

Thank you for your quick response! I am using the stable version from PyPI. I'll send you a copy of my script to look at. I apologize in advanced if this is some kind of misdeclaration on my part.

Thank you,
Madison

@nilp0inter
Copy link
Contributor

I think I managed to find the issue.

Your code is using OR field constraints extensively. For example:

@Rule(
   somefact1(somefield=L('value1') | L('value2') | L('value3') | L('value4'),
   somefact2(somefield=L('value4') | L('value5)...
)
...

This result in an internal combinatorial explosion which is the cause of the long initialization time.

I will keep this issue open to address this bug in the future, improving the internals to optimizing this kind of expressions automatically.

In the meantime you can circumvent the problem with a little change in your code.
Instead of using the above construction, you can write a helper like this one:

def anyof(*what):
    return P(lambda y: y in what)

Then, you can change your rule to use the helper function like this:

@Rule(
   somefact1(somefield=anyof('value1', 'value2', 'value3', 'value4'),
   somefact2(somefield=anyof('value4', 'value5)...
)

Once you change your code, please let us know if the performance improved.

Thank you for helping us on catching this bug!

@nilp0inter nilp0inter added the bug label Feb 27, 2018
@ab612
Copy link
Author

ab612 commented Mar 1, 2018

Thank you so much!
This completely fixed my problem. My initialization time went from 12 minutes to 1 second, and my reset time also went from 12 minutes to 1 second. The time to run the engine, declare facts, and reset the engine after it has been run once have all improved from approximately 30 seconds to near instantaneous.
Thank you again and have a nice day!

@nilp0inter
Copy link
Contributor

Since version 1.2.0 the helper anyof is available in the pyknow.utils module.

I opened #10 to address the combinatorial explosion problem and I am closing this issue now.

Thank you again for reporting this issue.

Best regards,
Roberto

@shahintaj196
Copy link

hello.I want to mesure policy proccessing time in my code?
what shoud i do?
for example in below code how obtain policy(rule) procceing time?

class animal(Fact):
pass
class age_animal(KnowledgeEngine):
@rule(animal(age='1'))
def f1(self):
print("young")

class P(KnowledgeEngine):
@rule(animal(age='7))
def f2(self):
print("old")

engine = age_animal()
engine.reset()
engine.declare(animal(age=input("Enter age value:\n") ))
engine.run()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants