Optimize Generated Code for Lookup Table Blocks

Remove Code That Checks for Out-of-Range Inputs

By default, generated code for the following lookup table blocks include conditional statements that check for out-of-range breakpoint or index inputs:

To generate code that is more efficient, you can remove the conditional statements that protect against out-of-range input values.

Block	Check Box to Select
1-D Lookup Table	Remove protection against out-of-range input in generated code
2-D Lookup Table
n-D Lookup Table
Prelookup
Interpolation Using Prelookup	Remove protection against out-of-range index in generated code

Selecting the check box on the block dialog box improves code efficiency because there are fewer statements to execute. However, if you are generating code for safety-critical applications, you should not remove the range-checking code.

To verify the usage of the check box, run the following Model Advisor checks and perform the recommended actions.

Model Advisor Check	When to Run the Check
By Product > Embedded Coder > Identify lookup table blocks that generate expensive out-of-range checking code	For code efficiency
By Product >Simulink Check > Modeling Standards > DO-178C/DO-331 Checks > Check usage of lookup table blocks	For safety-critical applications

For more information about the Model Advisor, see Check Your Model Using the Model Advisor in the Simulink^® documentation.

Optimize Breakpoint Spacing in Lookup Tables

When breakpoints in a lookup table are tunable, the spacing does not affect efficiency or memory usage of the generated code. When breakpoints are not tunable, the type of spacing can affect the following factors.

Factor	Even Power of 2 Spaced Data	Evenly Spaced Data	Unevenly Spaced Data
Execution speed	The execution speed is the fastest. The position search and interpolation are the same as for evenly-spaced data. However, to increase speed a bit more for fixed-point types, a bit shift replaces the position search, and a bit mask replaces the interpolation.	The execution speed is faster than that for unevenly-spaced data because the position search is faster and the interpolation uses a simple division.	The execution speed is the slowest of the different spacings because the position search is slower, and the interpolation requires more operations.
Error	The error can be larger than that for unevenly-spaced data because approximating a function with nonuniform curvature requires more points to achieve the same accuracy.	The error can be larger than that for unevenly-spaced data because approximating a function with nonuniform curvature requires more points to achieve the same accuracy.	The error can be smaller because approximating a function with nonuniform curvature requires fewer points to achieve the same accuracy.
ROM usage	Uses less command ROM, but more data ROM.	Uses less command ROM, but more data ROM.	Uses more command ROM, but less data ROM.
RAM usage	Not significant.	Not significant.	Not significant.

Follow these guidelines:

For fixed-point data types, use breakpoints with even, power-of-2 spacing.
For non-fixed-point data types, use breakpoints with even spacing.

To identify opportunities for improving code efficiency in lookup table blocks, run the following Model Advisor checks and perform the recommended actions:

By Product > Embedded Coder > Identify questionable fixed-point operations
By Product > Embedded Coder > Identify blocks that generate expensive saturation and rounding code

For more information about the Model Advisor, see Check Your Model Using the Model Advisor in the Simulink documentation.

Reduce Data Copies for Lookup Table Blocks

When you use workspace variables to store table and breakpoint data for Lookup Table blocks, and then configure these variables for tunability, you can avoid data copies by using the same data type for the block parameter and variable. Workspace variables include numeric MATLAB^® variables and Simulink.Parameter objects that you store in a workspace, such as the base workspace, or in a data dictionary. If the data type of the variable is smaller than the data type of the block parameter, the generated code implicitly casts the data type of the variable to the data type of the block parameter. This implicit cast requires a data copy which can potentially significantly increase RAM consumption and slow down code execution speed for large vectors or matrices.

For more information, see Parameter Data Types in the Generated Code (Embedded Coder) and Create Tunable Calibration Parameter in the Generated Code (Simulink Coder).

Efficient Code for Row-Major Array Layout

To generate efficient code for row-major array layout, select the model configuration parameter Math and Data Types > Use algorithms optimized for row-major array layout. The row-major algorithms perform with the best speed and memory usage when operating on table data with row-major array layout. Similarly, the default column-major algorithms perform best with column-major array layout. Consider using the algorithm that is optimized for the specified array layout to achieve best performance. For example, use row-major algorithms when array layout is set as row-major during code generation.

Array Layout	Algorithm	Cache-Friendly Algorithm
Column-major	Column-major	Recommended
Row-major	Row-major	Recommended
Row-major	Column-major	Not recommended
Column-major	Row-major	Not recommended

For more information, see Column-Major Layout to Row-Major Layout Conversion of Models with Lookup Table Blocks (Simulink Coder).