Improving performance on large rule projects
In large rule projects, you can improve the performance of Rule Designer.
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 up 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 .
- Select
When you save a rule project item, Rule Designer automatically generates IRL code and runs some checks on this code, including rule analysis. You can choose to disable the rule analysis checks only, or to disable all checks by clearing the Perform IRL checks during build option.
If you disable these options, you do not receive warning and error messages when saving your rules, but the rule project build is faster. However, more time is required when you extract a ruleset archive from the rule project, because the IRL code is generated and checked at that point. You can also disable IRL code generation to make the build even faster.
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. The guided editor behavior is not affected because it does not support the Quick Fix feature.
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 up 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 executes the rulesets.
Upgrading to 64-bit Java SDK
If your system configuration supports it, run Rule Designer with 64-bit Java™ SDK to help building large projects if memory runs scarce.