Indexed fields should not be an issue for this.
Please describe your layout.
Is this a list or table view so that you get many records listed?
Are there summary fields on the layout?
Are their calculation fields that refer to related records in order to compute a value on the layout?
Do you have other unstored calculations--such as one that uses getNthRecord to refer to other records in the found set?
Do you have conditional format or Hide Object When calculations that refer to summary fields or aggregate (sum, average, max, list...) data from related records?
These are all things that can slow a layout's update down and is a non-linear function of the number of records in your found set.
Phil has expertly hit on just about every conceivable slow down possible. If you still can't find the culprit, try duplicating your layout and remove objects until it speeds up. By process of elimination you will know the cause and then be able to address the issue with an alternative approach.
thanks for your answer.
Yes this layout is complex. If there is tab panel can it be on one of the subpanel or it can only be in the first displayed ?
I have to look into all ?
Objects on panels not displaying will not cause the slow down.
Yet another problem I sometimes observe involves out-of-context sorting.
Let's say you have a portal on your layout and it is sorted by a field that is in the child record.
Again for sake of discussion, the portal contains order items and is sorted by orderItem::productID.
But actually, the current layout is based on Salesperson and the portal contains MyOrderItems; including MyOrderItems::ProductID. But the sort order is still based on OrderItems::productID.
Does any feature of this layout involve a sort order; and is it the RIGHT sort order in the current context?
Maybe the sort order was originally set up wrong.
Or maybe it was originally set up correctly; and some feature has been re-purposed.
Filtered portals if there are large numbers of related records, can also slow things down.
thanks for all this ideas.
SQL calculated fields can also or less possible ?
Yes, an unstored calculation field that uses ExecuteSQL could slow down layout updates.
Sometimes you just need to keep your found set smaller and avoid things like show all records. If this is a report layout, a script can enter Find Mode first, then change layouts to this layout before performing a Find to produce the report.
if you have multiple windows open of the same base table and an open (not-committed) record then using an unstored SQL evaluated calculation field can become super slow if there are more then 100 records of this table's total record count (hosted or not).