Filter-NAC Optimisations

[anthonyanjorin]

Filter NACs can be quite costly (we don't yet know how costly).

Here are some ideas to reduce the number of filter NACs we currently generate:

• Don't generate filter NACs if the forbidden structure is impossible anyway (multiplicities 0..1, container semantics, multiplicities and other matched edges in the same pattern?, ...)
• Check if we handle the case where the forbidden edge can never be translated anyway with the rules of the TGG (and if we handle this generally enough)

[Arikae]

The first point makes sense, isn't that something where we could possible reuse some code/logic from our pattern optimization?

About the second point, we already do this with the current filter NAC generation or do you mean more general cases?

[anthonyanjorin]

Can't remember --- but when optimising we found some examples where the generated filter NACs were a bit paranoid (and could be omitted).

After refactoring and cleaning up the code, I guess one would have to go through our TGGs and inspect randomly the generated filter NACs.