Improving performance on large rule projects
When your rule projects grow larger, you can usually improve Rule Designer performance by using some Rule Designer build configurations that are better suited to large projects, limiting the BOM footprint, and reducing the size of business rule artifacts.
Disabling the automatic build
By default in Eclipse, a build process is started as soon as a resource changes in the workspace. As a consequence, as soon as you save a file in Rule Designer, a build runs. The build is usually incremental and fast, so there is no particular issue with the fact that it runs regularly. However, if you make changes that affect the rule project globally, such as modifications on the business object model (BOM), the build might have to recheck many elements. The build can be slow if your project is large.
Deselect to disable the automatic build.
If you disable the Eclipse automatic build, rule refactoring might not always be activated. In this case, you must explicitly ask for a build to refresh the errors in the Problems view.
Setting preferences for a faster build
When you have a large rule project, particularly one with many decision tables and ruleflows, the build can become slower. In Rule Designer you can define preferences for the rule project build.
- To access the build preferences page, select . (On Mac, click .)
- Select
- Set your preferences.
| Preference | Description |
|---|---|
| Build rules for which the property "active" is false | This preference builds all the rules. Deselect this preference to build only the active rules and reduce the build time. |
| Perform BOM to XOM checks during build | The preference verifies the conversion of BOM to XOM during the build. Deselect this preference to not perform the check and reduce the build time. |
| Perform rule analysis during build | When you save a rule project item, Rule Designer automatically generates IRL code and runs some checks on this code, including rule analysis. Deselect this preference to stop the analysis and reduce the build time. |
| Incremental build with optimistic vocabulary impact | This preference uses impact tables that are finer grained than those in the regular build. Without this option, any change to the BOM triggers a full build of all the rules. Select this preference recompile only the rules that are related to the changed vocabulary. |
| Generate ARL info to output folder for debugging | More time is required when you extract a ruleset archive from the rule project because the ARL code is generated and checked at that point. You can disable ARL code generation to make the build even faster. This preference generates an ARL file of all rules in the archive. The file can be used in debugging. If you select this option to produce an ARL file, it will increase the build time. |
| Lazy load rule artifacts | By default, the rule model loads everything. Select the preference to load only the edited artifacts. |
Limiting the number of business rules in rule packages
- Rule Designer loads only the required packages. If all your rule artifacts are stored in a single package, Rule Designer must load all the rule artifacts when you start it. If your rules are organized into packages, Rule Designer loads only the rule artifacts from the required packages.
- To resolve the fully qualified name of a rule, Rule Designer navigates through
packages to find the rule. If the tree of packages is well distributed, Rule Designer accesses the rule
faster. Note:
The fully qualified name of a rule is the short name of the rule prefixed with its package name.
However, make sure that you do not have too many small packages, because looking for rule model elements slows down Rule Designer.
Reducing the business object model footprint
When your rule project contains a large business object model (BOM), the features related to business rule language are slower. Parsing, checking, Content Assist, and navigation in business rules and technical rules is slower with large business object models.
- BOM size
-
- Reduce the BOM size by removing unused verbalizations, BOM members and classes: When you define a BOM entry from a XOM, the BOM entry might include numerous technical classes and methods that are not actually used in your rules. Because the size of the BOM affects Rule Designer performance, it is better to remove all unused business elements from the BOM.
- Split the BOM into several smaller BOMs that can be spread among your rule projects. See Setting up a project hierarchy.
- BOM tree
- Collapse the BOM tree in the Rule Explorer View before saving any changes to the BOM and starting a build. A collapsed BOM tree significantly reduces the time taken to build the project.
- Vocabulary parsing
-
A large BOM with many verbalizations might cause noticeable pauses in Rule Designer. To improve performance, you can reduce the time taken by BRL parser generation by disabling this option: . As a consequence, the user is no longer prompted with Quick Fix suggestions when editing rules with the IntelliRule editor.
Limiting the size of decision tables and decision trees
Decision tables that contain more than 3,000 rows, given a reasonable number of columns, significantly increase editing and build time. Tables with many columns should have fewer rows, because the main scalability factor is the number of cells.
- If possible, break up your large decision tables into smaller tables to improve their response time and make it easier to maintain their contents.
- Disable overlap and gap checking.
- Set up the build to disable IRL generation and checking. See Setting preferences for a faster build.
Limiting the size of RuleApps
When a RuleApp archive is generated, the number and size of its rule artifacts account for most of the resource consumption.
- Transform each large rule project into several smaller ones.
- Keep each rule project as it is, and generate multiple smaller rulesets out of it. You can use ruleset extractors, one per ruleset, to extract part of the rule project. In this case, you might have to change the application that runs the rulesets.