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

Provide "clear" or "reset" method for pattern matcher #24

Open
anthonyanjorin opened this issue Sep 3, 2017 · 4 comments
Open

Provide "clear" or "reset" method for pattern matcher #24

anthonyanjorin opened this issue Sep 3, 2017 · 4 comments

Comments

@anthonyanjorin
Copy link
Contributor

anthonyanjorin commented Sep 3, 2017

Hi Greg,

in addition to optimising the initialisation process (see #17) it would be great to have a method NotificationCollector.uninstall(Notifier notifier) as a counterpart to NotificationCollector.install(Notifier notifier) used to install a resource set.

The idea would be that uninstall puts the pattern matcher again in a state where install can be called for a new resource set without incurring any memory leaks (so pairs of install/uninstall can be invoked without having to repeat the costly initialisation process). I have tried to hack this myself but it doesn't make much sense (and I still eventually run out of memory).

Cheers and thanks,
Tony

@anthonyanjorin
Copy link
Contributor Author

@greg: you could also just give me some hints how to do this (if it can be done externally). I just tried reinstalling a new resource set and that works (tests are green) but quickly leads to an out-of-memory. Can I somehow detach all listeners on the old resource set? Would that be sufficient? Or does the pattern matcher have an internal state that has to be cleared?

@gervarro
Copy link

gervarro commented Sep 5, 2017

Hi Tony,

detaching all listeners on the old resource set is standard EMF. The pattern matcher has obviously an internal state (i.e., the partial and complete matches) that has to be cleared as well. Let me experiment with the search plan generation first, because it can still be significantly improved for special cases like this, where the patterns are known not to be disjoint. The current search plan algorithm handles even the most general cases (i.e., disjoint constraints), which makes the execution time considerable larger. The other option is to decrease the algorithm parameter, although I do not know whether this feature is accessible on the public interface of the pattern matcher.

Bests,
Greg

@anthonyanjorin
Copy link
Contributor Author

Thanks, Greg! I'll prepare some instructions for you soon explaining how you can run all our current tests and so see for a wide range of different TGGs how much your optimisations help. That should be helpful I think.

Cheers,
Tony

@anthonyanjorin
Copy link
Contributor Author

Btw: although most or at least many of our patterns are not disjoint, there can be TGGs for which this is not true for all patterns (edge rules). The safest would be perhaps to quickly check first if the pattern is disjoint or not?

Cheers,
Tony

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

No branches or pull requests

2 participants