Optimization of gatekeeper rule evaluation

[Pasi Paasiala]

Lately we have noticed that gatekeeper rules are heavily used and in ways that we couldn’t imagine when the feature was implemented. The original idea was that rulesets would have few gatekeeper rules and those rules would be ones that are fast to evaluate. This is the reason we made the rules react to changes in the models so that the tree in Checking view would always reflect what rules would be evaluated in the next check.

When we see how the rules are used in reality, we see that there are rulesets that have lots of gatekeeper rules and also the rules that are used as gatekeeper are not the fastest to run, This causes the rule tree update to take a lot of time and SMC feels sluggish.

In development we have found some optimizations that will make the tree update faster, but it is still unacceptably slow with large models and complicated rulesets.

We trying a change where change to model wouldn’t update the rule tree, but just leave the it to “Unsynchronized” state, which happens also with rulesets that don’t have gatekeeper rules.

When checking is done, the tree structure changes so that the end result is the same as it is in the current release version.

Is there someone who thinks this is a bad idea?

[bospaul]

I think this would be a great idea. Let the user decide whether or not synchronization is necessary. I think this might even be usefull with classifications (updating 5 models, and synchronizing after all 5 models are updated instead of after each model).

[Matti]

The optimization of gatekeeper rule evaluation is included in the Solibri Model Checker 9.9.4.98. It is available now.