|Bookshelf Home | Contents | Index | PDF|
Activate the object definitions that your applications require, and deactivate those that are not required. Doing this will result in a smaller SRF, thereby improving performance and scalability. It will also reduce the complexity of generated SQL and the infrastructure to support it.
Application performance improves when the SRF is smaller, particularly when it includes fewer object definitions that must be instantiated. In general, it is advisable to set unneeded object definitions to the status Inactive (Inactive property is set to TRUE), so they will be excluded when the SRF is compiled. The Inactive property applies to every object type.
For example, suppose you have a business component that is invoked by two scripts. One script is invoked rarely but requires all the business component fields to be active. Another script is invoked frequently and requires only a few fields. In this case, you could copy the business component, and set fields to Inactive in the version of the business component invoked by the script that does not require these fields. The benefit will be that fewer unnecessary object instantiations will occur. The tradeoff is that a larger SRF is required. The tradeoff may be worth it based on the performance implications, particularly when many fields are involved.
Setting unneeded object definitions to an inactive state results in a smaller SRF (unless, of course, you create additional object definitions by denormalizing) and smaller objects such as business components, and thereby improves performance and scalability. It also reduces the complexity of generated SQL and the infrastructure needed to support it.
NOTE: The property Force Active, which applies to certain object types, including business components and fields, does not override the Inactive property. Force Active only affects object definitions for which Inactive is set to FALSE. For more information, see Limiting the Number of Active Fields.
|Performance Tuning Guide|