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.

Design with Performance in Mind

• 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.

FlowScript Specific Optimizations

Avoid Nested Loops

• Poor Practice: Nested loops in large datasets cause performance bottlenecks.

• Optimized Approach: Reduce nesting by preprocessing data or using efficient data structures.

Use Eval() for Reused Table Expressions:

• Poor Practice: Repeated evaluation of the same condition.

  for DataRow in DS_MyData {
     let mySum = case when x then tmpTab WHERE X = DataRow.X AND Y = 't1'
                      when y then tmpTab WHERE X = DataRow.X AND Y = 't2' end;
  }

• Optimized Approach: Use Eval() to evaluate once, then reference the result.

  for DataRow in DS_MyData {
     let preEvaluatedCondition = Eval(tmpTab where X = DataRow.X);
     // Subsequent operations using preEvaluatedCondition
     let mySum = Eval(case when x then preEvaluatedCondition WHERE Y = 't1'
                           when y then preEvaluatedCondition WHERE Y = 't2' end);
  }

Efficient Data Grouping:

• Poor Practice: Inefficient data processing without grouping.

• Optimized Approach: Use group-by or inner join for data aggregation.

  let joinedData = DS_MyData INNER JOIN DS_Another ON MyId=OtherId;
  // Process joinedData

Code Clarity and Testing

• Clarity: Ensure Flow Script is clear and maintainable.

• Testing: Regularly test scripts to avoid performance issues in production environments.

Documentation

• Comprehensive Documentation: Maintain detailed documentation for each script, including functionality and special considerations.

Flow Studio Performance Tips

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.

Portal Performance Tips

• 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).

Gantt Portlet Performance

• 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.