Performance considerations  

The gadget spec URL could not be found

S.No	Performance consideration	Limitation/Constraint	Impact	Suggested alternative
1	Number of objects in a form page	A page should deal with a maximum of 100 objects.	Page takes a longer time to load.	When the number of objects to be displayed exceeds 100 objects, group relevant data and use multiple forms to capture/display data.   In cases where a tabbed menu form that exceeds the maximum limit for objects per page is used, design each tab as a separate form and use goto links to navigate to these forms instead of using a single form with show/hide privileges configured to display relevant tabs on selection.
2	Number of items in a select box	A dropdown select-box must not have more than 100 items.	Page takes a longer time to load and the response is slower.	It is a common practice to create a look-up relationship between models to provide a select-box with a dropdown. When the number of items in the dropdown select-box is more than 100, provide the advanced search feature by enabling the advance search option available in the “Connect” reference cell wizard.
3	Number of child model instances displayed in a parent form	Avoid using One-Many forms when the number of child model instances is greater than 25.	Page takes a longer time to load or page is unresponsive.	If the data from the child model has to be displayed, then an additional reference with the filter criteria to restrict the child records can be created in the child model and used to display the data. This is not recommended as it would involve creating an additional (unwanted) reference specifically for the user interface.
4	Number of objects processed by a R-Call or Child Call in an action	The system does not place a constraint on the number of records that can be processed. However, ensure that the number of objects processed by an R-Call or a Child Call in an action is not more than 100.	There will be a performance degradation associated with processing greater than 100 objects. The performance degradation will essentially translate into slower response times in the user interfaces.	Where appropriate, use limit or criteria to control the number of records processed by these commands.
5	Number of parent-child relationships	There are no constraints on the number of parent-child relationships that can be created, but it is important to understand the inherent behavior of a parent-child relationship and create these relationships judiciously, only where it is required.	A parent-child relationship will automatically perform a sync to keep the data consistent in the parent and child models. This could become a performance overhead when a parent-child relationship is implemented unnecessarily where only a master look-up is required.   OrangeScape provides a unique set of database functions such as DCOUNT, DCOUNTA, DCONCATENATE, DSUM, DMAX, DMIN, and DFIND to operate on the child model instances from the parent model. Similarly, it also provides a DGET function to fetch the parent model values from the child model. When these functions are used in the rules perspective (defined directly in the public cells), these will be executed always to keep the parent model values in sync with the child model. Any changes in the child model will automatically fire the rules in the parent model and vice-versa.	Parent/Child relationships must be created only to implement composition relationships, where the lifetime of the child is dependent on the lifetime of the parent i.e. every child of the parent is deleted when the parent is deleted, and NOT for the auto sync feature of parent/child relationships.
6	Using SYNC in database functions	The SYNC parameter can be set to TRUE while writing a database function in a rules perspective to keep the data consistent between any two connected models (look-up relationship) for upto 100 objects.	There will be a performance degradation associated with using SYNC when the number of objects is greater than 100.	By default, SYNC is TRUE for a parent-child relationship and FALSE for a look-up relationship.   When the objects are greater than 100, use database functions in actions or incremental logic in actions instead of aggregate functions such as DCOUNT, DCOUNTA, and DSUM in rules perspective.   If a DGET function is used to fetch the data only for displaying it in the user interfaces, then a many-one form must be used to display the data from the connected model. This also eliminates the need to use sync in the functions to keep the data consistent with the master model. Please note that this must be done irrespective of the number of the objects.
7	Using DSEARCH and DFIND	The older version of the DSEARCH returned the value requested in the function. In cases, where more than one field value was required, multiple DSEARCH had to be written in the rules perspective. In the current updated version of the DSEARCH, the SheetId of the instance matching the specified criteria is returned. By establishing a formula reference on the DSEARCH field, any value from that instance can be fetched. This removes the need for multiple DSEARCH that was required earlier.   The DFIND function can be used to search for an instance satisfying the required criteria in the child model while DSEARCH can be used to search for an instance satisfying the required criteria in ANY of the models, not restricted to child models alone.   When a DFIND is used to search the child model instances, it does a search on the child model instances of the particular parent model instance being processed. If a DSEARCH is used for the same purpose, it would search all the instances in the child model. Hence, DSEARCH can be substituted for DFIND. However, DFIND is likely to yield better performance than DSEARCH for a fewer number of objects (in the hundreds) to be searched.	There will be a performance degradation associated with processing greater than 100 objects when DFIND is used.   DSEARCH function does a query directly on the database whereas DFIND function loads the objects into memory for processing.	Firstly, all the depreciated API’s (Older DSEARCH function) must be replaced with the updated version of the DSEARCH.   Secondly, DSEARCH function can be leveraged (used instead of DFIND) for improved performance when the number of objects to be searched is greater than 1000 while using DFIND for less than 100 objects.