Are match sets of patterns which are initialized but which are not being used by other patterns and which have no match update listeners attached fully updated upon a model change? Or are they ignored? Does this hold both for the Rete engine and the local search engine?

Is there an easy way to see how much time is spend computing/updating the match sets of patterns individually upon initialization/after a model change? So that we know how much time is spend dealing with pattern A, dealing with pattern B, etc.

If pattern A uses pattern B and the model is modified such that pattern B has many added/removed matches, do both engines wait until the match set of B is stabilized before updating the match set of pattern A? Is it possible to enable this? E.g. something like a priority/delayUpdatPropagation but for propagation matches between patterns?

Regarding setting parameters as incoming/outgoing , what exactly does it mean for a parameter to be "bound when the pattern matcher initializes"? Does this increase performance?

If we get a warning that "pattern body contains constraints which are only loosely connected. This may negatively impact performance. The weakly dependent partitions are: [......]". However we know the partitions are connected through another pattern in an aggregator. Can we add this information somehow?

For example, I have the following pattern:

pattern RSD(role: Role, scenario: java Scenario, demarcation: Demarcation) {
find Scenarios(scenario);
find connectedByTemporalGrantRule(role, demarcation);
maxEnabledPriority == max find EnabledPriority(scenario, role, demarcation, #p);
maxDisabledPriority == max find DisabledPriority(scenario, role, demarcation, #p2);
maxEnabledPriority > maxDisabledPriority);
} or {
find Scenarios(scenario);
find connectedByTemporalGrantRule(role, demarcation);
find EnabledPriority(scenario, role, demarcation, _);
neg find DisabledPriority(scenario, role, demarcation, _);
}



Here, we get the warning that "The pattern body contains constraints which are only loosely connected. This may negatively impact performance. The weakly dependent partitions are: [maxEnabledPriority][role, demarcation][scenario][maxDisabledPriority]". However, we know that maxEnabledPriority and maxDisabledPriority are found given sets of [role, demarcation, scenario] in the patterns EnabledPriority/DisabledPriority. Can we add this information somehow?

Not really. We never had a case where this seemed important.

The somewhat counterintuitive aspect of VIATRA is that adding extra constraints may even improve performance as those extra constraints can greatly reduce the number of objects to consider.

pattern SecurityZoneAccessible(user: User, scenario: java Scenario, zone: SecurityZone) {
	SecurityZone.public(zone, true);
	find SecurityZoneAccessStatus(scenario, zone, 0);
	User(user);
} or {
	find USO(user, scenario, zone);
	SecurityZone.public(zone, true);
	find SecurityZoneAccessStatus(scenario, zone, 1);
} or {
	find SecurityZoneAccessible(user, scenario, prev);
	find SecurityZoneAccessibleIntermediate1(scenario, prev, zone);
} or {
  	find SecurityZoneAccessible(user, scenario, prev);
  	find SecurityZoneAccessibleIntermediate2(user, scenario, prev, zone);
 }

pattern SecurityZoneAccessibleIntermediate1(scenario: java Scenario, prev: SecurityZone, zone: SecurityZone) {
	find SecurityZoneAccessStatus(scenario, zone, 0);
	SecurityZone.reachable(prev,zone);
}

pattern SecurityZoneAccessibleIntermediate2(user: User, scenario: java Scenario, prev: SecurityZone, zone: SecurityZone) {
	SecurityZone.reachable(prev,zone);
	find SecurityZoneAccessStatus(scenario, zone, 1);
	find USO(user, scenario, zone);
}