You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
@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?
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.
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.
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?
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 toNotificationCollector.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
The text was updated successfully, but these errors were encountered: