Guidelines for 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.

To toggle the Eclipse automatic build option, select Project > Build Automatically.

Note:

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 rule flows, the build can become slower. In Rule Designer you can define preferences for the rule project build.

To access the build preferences page, select Windows > Preferences.
Select Rule Designer > Build
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.

Note:

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 is more efficient when you work with several small or medium-sized packages, as opposed to a few large packages, for the following reasons:

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.

To reduce the BOM footprint, you can apply the following techniques:

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 Guidelines for organizing your application into rule projects.

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: Window > Preferences > Rule Designer > Business Rule Editing > Enable Quick Fix. 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.

In Rule Designer, you can significantly improve the usability and performance of large decision tables and trees:

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.

To reduce the resource usage cost of a business rule application, you can apply the following techniques:

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.