Performance Guidelines
As a Novacura Flow designer, you are partly responsible for the performance of the applications you create with Novacura Flow. This chapter contains design guidelines that are important to consider.
Always try to filter down your data before displaying it. It takes time to both fetch data and to render it on screen. Using a search predicate to narrow down the data before working with it if possible (i.e. a where clause in SQL or filters in REST etc.). This will free up resouces both on your data layer, network, servers and clients.
When retreiving data from a database, if possible, use fields that are indexed. It is probably also faster to put the logic in the sql query rather than fetching everything and then make logic in flow script. As this case by case, just have performance in mind.
Fetch all independent data using data arrows. This will ensure that the data is fetched simultaneously. In the below example, the execution time would have been 15 seconds if the machine tasks were placed in a line. Using data arrows like, in this example, the execution time will be 10 seconds.
- For the portal, some portlets are more sensitive than others. A table has an easier time keeping 100 000 records than for example the Kanban portlet which has a much more complex rendering process. 100 000 cards would not only be rather impossible to scroll through, but it will also take time to render all the cards. The more complex portlet, the more important it is to narrow down the data.
- Always try to use OnRowSelected rather than OnFilter, no matter if filtering from a filter or other portlet. OnFilter retrieves all the data and filters, while OnRowSelected will predicate the search with search parameters (i.e. using them in a where clause in SQL).
- Consider the "Enable virtual scrolling" setting under GENERAL - ADVANCED SETTINGS to set how the tasks are rendered. If Enable virtual scrolling is not set, all tasks returned by the query will be rendered, regardless of if they are seen on the screen or not. If it is set, only the tasks seen are rendered directly, and tasks are continued to be rendered as the user scrolls in the Gantt. This setting can greatly enhance the experienced performance in scenarios with a long task list, but could also appear a bit flickery since it re-renders the screen more often
- The Gantt portlet has the option to use hierarchical data (tasks consisting of other sub-tasks) and a numerical value should be used for matching id. Using long special character columns as the id could have a significantly negative impact on performance. For example, if there are 5 entries where id 1 is the parent of 3,4 and 5, matching the parent and children on the "Name" column is a larger performance hit than matching a numerical value.
- Tests have shown that a short text string, for example, Char(5), is much faster than a longer one. The same thing goes for spaces which should be avoided if possible. If numeric is not an option, try to keep the ids to short strings without special characters and spaces.
Last modified 2mo ago