Family Table Instance Retrieval Time
This document describes the effect of feature regeneration order on family table instance retrieval time.
This document applies to all models which will have family tables. The performance improvements to be gained from the information below can sometimes be seen best with assemblies which use many very simple bolt, washer, etc. types of family table models.
Feature regeneration order can have a significant impact on family table instance retrieval time.
The general rule is that when an instance is retrieved, Pro/ENGINEER will regenerate from the first modified feature. After design intent has been satisfied during creation of a model, designers should attempt to move features that are going to be modified in a family table instance to as late in the regeneration order as possible (using #Feature, #Reorder and other complimentary techniques). This way, when the instance is retrieved, a minimum number of features will require regeneration.
The following simplified example illustrates this behavior:
1) Create a part consisting of a simple rectangular protrusion.
2) Create a hole feature.
3) Create a second hole feature.
4) Add the diameter dimension of the first hole feature to the family table.
5) Create a family table instance by editing the family table, creating a new row with the name of the instance, and enter a value for the diameter dimension that is different than the generic.
6) When the instance is retrieved, Pro/ENGINEER will regenerate the feature starting at feature #2, which is the hole whose diameter was modified. This can be seen by viewing the message log using #Info, #Message Log.
When the instance is retrieved the first hole must regenerate and after this the second hole must also regenerate. The regeneration of the second hole is unnecessary, however, because it is independent from the first. The performance of retrieval of the instance can be easily improved by reordering the first hole feature to come after the second hold feature. If this reorder is performed, the only feature which will need to regenerate is feature #3.
This example can be expanded to more complicated model. For example, if the model consisted of 100 features, the performance issue would be readily apparent.
One warning, however: design intent must always be taken into consideration first. If reordering the feature causes the model geometry to be changed unacceptably, then either the reorder should not be performed or the designer should determine if there is an alternate method for creating the part geometry which will allow the modification to occur as late in the regeneration order as possible.