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.
Last updated
Was this helpful?
Data Filtering: Filter data at the source (e.g., SQL where clauses, REST filters) to minimize resource usage across data layers, networks, servers, and clients.
Indexed Fields in Database: Use indexed fields when retrieving data. Embedding logic in SQL queries is often more efficient than processing in FlowScript.
Poor Practice: Nested loops in large datasets cause performance bottlenecks.
Optimized Approach: Reduce nesting by preprocessing data or using efficient data structures.
Poor Practice: Repeated evaluation of the same condition.
Optimized Approach: Use Eval() to evaluate once, then reference the result.
Poor Practice: Inefficient data processing without grouping.
Optimized Approach: Use group-by or inner join for data aggregation.
Clarity: Ensure Flow Script is clear and maintainable.
Testing: Regularly test scripts to avoid performance issues in production environments.
Comprehensive Documentation: Maintain detailed documentation for each script, including functionality and special considerations.
Parallel Execution: Fetch independent data simultaneously using data arrows to optimize execution time.
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.
Portlet Sensitivity: Understand the impact of large datasets on different portlets, and narrow down data accordingly.
OnRowSelected vs. OnFilter: Use OnRowSelected for efficient data retrieval, as it uses search parameters in SQL.
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 would also take time to render all the cards. The more complex the portlet, the more important it is to narrow down the data.
Always try to use OnRowSelected rather than OnFilter, whether 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).
Virtual Scrolling: Enable virtual scrolling for better performance with long task lists. 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 whether they are seen on the screen or not. If it is set, only the tasks seen are rendered directly, and tasks continue 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
ID Optimization: Use numerical values for IDs in hierarchical data. Avoid long text strings, special characters, and spaces. 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.
