Form performance killers – Display Methods and per row or per control logic

Forms get slow when you compute data per row using X++ methods that hit the DB and that can be done in multiple, different ways.

Display Methods

Display methods are handy to have to get some arbitrary data points into a grid or onto a form. Also, display methods aren’t inherently bad – but using them in less than ideal situations can cause problems. For instance, a display method on a summary or confirmation form/dialog of some sort if perfectly fine. The performance penalty for using a display method is very small and it is likely the summary or confirmation form will have only 1 record so we’re doing something that can be slow but we’re only doing it once. That’s not ideal but it’s fine 98% of the time. However, if you throw something like below into a grid, that’s where problems can emerge.

display Qty availQty()

{

    InventSum inventSum;

    select firstOnly inventSum

        where inventSum.ItemId == this.ItemId;

 

    return inventSum.AvailPhysical();

}

On a grid with 500 rows, you just did 500 extra selects. That is likely to be noticed.

Potential fixes for this are to bring the data via a joined data source. With a joined data source, the data we’re looking for will be available when filling the grid so we don’t have to go get it as a separate operation. You could also use computed columns / view patterns for derived values if working with a view or data entity. Additionally, you can cache reference lookups depending on the form so even if you have to do something like get a record for each record in a grid, we can (sometimes) cache the results and those will be reused. Lastly, avoid calling heavy logic in active(), modified(), linkActive(), or similar. You may use active() for form state management (enable/disable buttons) but if you’re getting data, use executeQuery() whenever you can.

My yule of thumb is no DB calls inside display methods for grid-backed forms unless there is no other option.