G2 offers several compilation configurations:
stable- prefix configurations to declare that a portion of your KB is not subject to change, even when the KB is running. G2 consults these declarations when compiling items that refer to the stable portion of the KB. G2 compiles references to a stable item differently than it compiles references to an item that is not stable. For stable items, G2 can assume that the name, class, and item location in the KB's workspace will not change as the KB runs. Therefore, G2 compiles the referencing item in a way that reduces the number of validation checks G2 must perform when executing or evaluating the actions, statements, or expressions that refer to the stable item.
describe configuration menu choice to see all configurations that apply to an item. You declare an item to be stable or not by including one or more of these configuration statements in the item's
Item-configuration or Instance-configuration attributes:
declare properties ... as follows : stable-hierarchy
declare properties ... as follows : stable-for-dependent-compilations
declare properties ... as follows : independent-for-all-compilations
declare properties ... as follows configuration statement.
Understanding Compiled Attributes
In general, G2 compiles each item attribute that can contain an expression, an action, or a statement. These are called compiled attributes. Formula of a variable or the Expression-to-display of a readout-table.
Note: If you change a compiled attribute's value using the Text Editor, G2 recompiles that attribute after you direct G2 to save the attribute's edited text. If you make a valid change to a compiled attribute's value using a change the text of or conclude action, G2 automatically recompiles the attribute.
Validating References at Run-Time
The contents of a running KB are always subject to change. Therefore, when G2 compiles an attribute that refers to another item, G2 does not, by default, record any assumptions about the referenced item, such as whether that item actually exists or whether it is of a certain class. dependent-rule, shown in the following figure. The text of dependent-rule refers to a user-defined object named first-vehicle, whose class is vehicle, a user-defined procedure named update-tracked-vehicle-routes, and a user-defined object named current-checkpoint, whose class is CHECKPOINT:
|
By default, when G2 compiles this rule's text, G2 does not assume that
first-vehicle, update-tracked-vehicle-routes, and current-checkpoint exist. (Even if, for example, first-vehicle does exist at the time that G2 compiles this rule, the item might cease to exist, or its class's class inheritance path might change, before your KB next invokes the rule.) Therefore, in the rule's compiled instructions G2 includes run-time validation instructions.
first-vehicle exists, and its class is VEHICLE.
update-tracked-vehicle-routes exists, and its one argument is of type class checkpoint.
current-checkpoint exists, and its class is CHECKPOINT.
To apply this idea to your KB as a whole: the more items whose compiled attributes can avoid including run-time validation instructions, the greater the potential for an incremental improvement in your KB's performance.
To illustrate,
dependent-rule's antecedent refers to the item first-vehicle. Due to this reference, for your KB to invoke this rule without error requires that an item named first-vehicle exists in the KB, that first-vehicle's class is VEHICLE, and that the VEHICLE class maintain the same direct superior classes and direct subclasses that it has at the time dependent-rule is compiled. These requirements represent a compilation dependency between the rule and
first-vehicle. The diagram in the following figure represents this relationship graphically:
 |
Likewise,
dependent-rule has compilation dependencies on the existence of current-checkpoint and update-tracked-vehicle-routes.
You can make changes to stable items that do not affect those characteristics, such as concluding values into attributes, establishing relation instances, or storing items in lists.
Declaring Procedures and Methods as Inlineable
The inlineable configuration is applicable to:
inlineable,
inlineable, you must also declare it to be stable-for-dependent-compilations. When declaring a method as
inlineable, you must also declare it to be stable-hierarchy and stable-for-dependent-compilations.
inlineable, and making it stable with its other required configuration statements, you must manually recompile both the inlineable item and the procedure or method that calls it. G2 does not present a recompilation dialog, though a message about recompiling is added to the Notes of the procedure or method. By recompiling the calling procedure or method, G2 compiles the inlined code as part of the calling code. Since inlined procedures and methods are compiled in their calling procedure, they do not require a procedure invocation at run time, and performance improves.
Editing an existing inlined procedure or method causes G2 to display a dialog indicating that the item is stable and editing could make recompilation necessary.
stable-hierarchy configuration is applicable to:
stable-hierarchy Declaring a method as
stable-hierarchy also implies that the return value types and the number and type of method arguments will not change. When you declare an item as
stable-hierarchy, G2 can complete optimizations, including inlining, only if these conditions are met:
stable-hierarchy.
fill method whose first argument is vessel, for optimization to occur, the class vessel could not have a subclass that defined a fill method with the same number of arguments. At run time, such a method hierarchy would make it impossible for G2 to know which method was actually being called, since the vessel class passed to the fill method could be either vessel or one of its subclasses.
stable-for-dependent-compilations configuration to an item upon which other items have a compilation dependency. If the item is an instance of a user-defined class, then for G2 to consider that item as stable, you must also apply a stable-for-dependent-compilations item configuration to the definition item for its class.
stable-for-dependent-compilations configuration to a set of items, use the Inspect facility to recompile your entire KB. Until you do so, your KB's performance cannot take advantage of the newly declared item stability. first-vehicle then recompile your KB, the compiled attributes in dependent-rule that have a compilation dependency upon first-vehicle no longer include instructions that check, for instance, whether first-vehicle exists. This helps dependent-rule execute more quickly than it could before first-vehicle was configured stable-for-dependent-compilations.
declare properties as follows : stable-for-dependent-compilations statement in the Item-configuration attribute of each top-level workspace in your KB. (This approach is especially preferred for modular KBs.)
declare properties as follows : not stable-for-dependent-compilations statement in the Item-configuration attribute of the workspace representing each subhierarchy of items that is subject to change.
 |
This Inspect workspace shows the workspace hierarchy for a simple KB that contains five workspaces. The items located in the
DEVELOPMENT-UTILITIES-WORKSPACE and CLASSES-WORKSPACE workspaces contain items that represent the KB's stable knowledge (items whose definitional characteristics don't change as the KB runs). GLOBAL-SCHEMATIC-VIEW-WORKSPACE and ZOOM-SCHEMATIC-VIEW-WORKSPACE workspaces contain items that represent the KB's dynamic knowledge (the items whose knowledge is expected to change as the KB runs). GLOBAL-SCHEMATIC-VIEW-WORKSPACE and ZOOM-SCHEMATIC-VIEW-WORKSPACE workspaces as not stable-for-dependent-compilations.
independent-for-all-compilations, G2 does not compile the item to take advantage of compilation dependencies upon any other items declared as stable-for-dependent-compilations. Declaring an item independent-for-all-compilations affects that item's compilation only if the item's compiled attributes reference other items. In general, only use this option if you don't trust stable configured items to remain stable, probably a rare occurrence. For example, if a compiled attribute in item
A depends upon other items, one of which (item B) is configured as stable-for-dependent-compilations, then you can declare item A as independent-for-all-compilations. This causes G2 to compile item A without taking advantage of any optimizations due to its dependency on item B.
independent-for-all-compilations, you can prevent your procedure from being subject to automatic recompilation due to changes in an item upon which it depends. Further, because other items in your KB depend upon your procedure, you can also configure it as stable-for-dependent-compilations.
To manage the activity of recompiling items in your own modular KB that depend on items in other modular KBs that you do not control, declare as independent-for-all-compilations all items in your modular KB that depend upon items in the provided KB.
 |
If your KB's processing deletes stables items programmatically, G2 does not prompt for confirmation.
After Changing the Knowledge of Items Declared Stable-for-dependent-compilations
For items that depend on an item declared stable-for-dependent-compilations, G2 compiles those items with the assumption that the following knowledge will not change:
change the name of action applied to the item that changes its Names attribute.
change the text of or conclude action applied to the Class-name or Direct-superior-classes attribute that changes the defined class's name or any direct superior class.
change the text of action applied to the item's text that changes the item's name, or the number and types of its arguments and returned values
make transient action applied to the item
 |
If you interactively edit a compiled attribute of an item declared stable-for-dependent-compilations, G2 displays the following dialog:
 |
Press OK to enter the Text Editor. Press Cancel to rescind your attempt to edit the attribute.
Notes attribute) is again OK. After Removing a Stable-for-dependent-compilations Configuration
Assume that your KB contains an item declared stable-for-dependent-compilations, and contains other items, each with its own compilation dependency relationship with the stable item. Further, assume that the dependent items have been compiled to take advantage of their dependency on the stable item. declare properties ... as follows : stable-for-dependent-compilations configuration statement from the stable item, you break the compilation dependencies among the KB's items. Therefore, after you remove a stable-for-dependent-compilations configuration from an item, G2 sets the OK/incomplete/bad status of the dependent items to incomplete. G2 also displays the dialog shown next:
 |
recompile every item whose status is incomplete
declare properties ... as follows : independent-for-all-compilations item configuration to the item.
declare properties ... as follows : independent-for-all-compilations item configuration.
incomplete, then displays the following dialog that initiates a recompilation of all items with incomplete status in the KB:
 |