Create Execution-Time Profile for Generated Code

You can configure a software-in-the-loop (SIL), processor-in-the-loop (PIL), or XCP-based external mode simulation to produce execution-time metrics for tasks and functions in your generated code. The software calculates execution times from data that is obtained through code instrumentation added to the target application or the generated code under test. You can use the execution-time metrics to determine whether the generated code meets the requirements for real-time deployment on your target hardware.

For example, you can perform the following analysis:

Identify tasks that require the most time. Tasks are main entry points into the generated code. For example, the step function for a sample rate or the model_initialize function.
In these tasks, investigate code sections that require the most time.
Identify variations in execution time over time steps.

If you are trying to reduce execution times, the analysis results help you to focus on the most critical code sections. To observe performance changes for an updated model, rerun the SIL, PIL, or external mode simulation and compare the new metrics against previous metrics.

When the SIL, PIL, or external mode simulation is complete, you can:

View execution-time metrics through a display panel, report, or in the Code view.
Use the Simulation Data Inspector to view and compare the variation of execution times over a simulation.
Analyze the measurements within the MATLAB^® environment.

Configure Code Execution Profiling

This table lists system target files that are supported for code execution profiling.

Simulation Mode	System Target File
SIL or PIL	GRT, ERT, or ERT-based
XCP-based external	ERT or ERT-based

To configure code execution profiling for a SIL, PIL, or XCP-based external mode simulation:

In your top model, open the Configuration Parameters dialog box.
Select the Measure task execution time check box.
For function execution times, from the Measure function execution times drop-down list, select one of these options:
- Coarse (referenced models and subsystems only) –– if you want to analyse generated function code for the main model components.
- Detailed (all function call sites) –– if you want to analyse generated function code for all blocks in the model.
Only ERT system target files are supported for function profiling.
In the Workspace variable field, specify a name. When you run the simulation, the software generates a variable with this name in the MATLAB base workspace. The variable contains the execution-time measurements, and is an object of type coder.profile.ExecutionTime.
If the Data Import/Export > Single simulation output check box is selected, the software creates the variable in the Simulink.SimulationOutput object that you specify.
From the Save options drop-down list, select one of these options:
- Summary data only — Stream execution times to the Simulation Data Inspector during the simulation. Store minimal information at the end of the simulation. Use this option if you want to generate only a report and reduce memory usage, for example, in a long simulation.
- All data — Stream execution times to the Simulation Data Inspector during the simulation. Store execution-time profiles in the base workspace and generate a report. After the simulation, you can use methods from the coder.profile.ExecutionTime and coder.profile.ExecutionTimeSection classes to retrieve execution-time measurements for every call to each profiled section of code that occurs during the simulation.
  If you select this option, the metrics display window and generated report display the Simulation Data Inspector icon . When you click the icon, the software imports simulation results into the Simulation Data Inspector. You can then plot execution times and manage and compare plots from various simulations.
- Metrics only –– Reduces bandwidth usage for the communication channel between Simulink^® and the target application. During the simulation, the software does not stream execution times to the Simulation Data Inspector. On the target hardware, the software stores maximum execution times, average execution times, and number of calls. At the end of the simulation, Simulink uploads the data from the target hardware to your development computer.
Click OK.

For a PIL simulation:

You must configure a hardware-specific timer. When you set up target connectivity, create a timer object. This action is not required for a SIL simulation. For more information, see Set Up PIL Connectivity by Using Target Framework or Create PIL Target Connectivity Configuration for Simulink.
You can remove instrumentation overheads from execution times. For more information, see Remove Instrumentation Overheads from Execution Time Measurements.

Control Profiling Granularity

You can control the granularity of execution-time profiling, that is, prevent the addition of code instrumentation to specific function-call sites. Through the control of profiling granularity, you can:

Focus on the performance of model components that require improvement. For example, after an initial run, disable profiling for blocks that require little processing time. This action reduces the number of items displayed by the profiling report.
Reduce the code instrumentation overhead. For example, for simple functions, the code instrumentation overhead can be greater than the execution time of the function code.

To generate execution-time metrics for tasks only, on the Code Generation > Verification pane of the Configuration Parameters dialog box, select the Measure task execution time check box and set Measure function execution times to Off.

To generate function execution data for referenced models and atomic subsystems in the top model, on the Code Generation > Verification pane, select the Measure task execution time check box and set Measure function execution times to Coarse (referenced models and subsystems only).

The generation of function execution data requires the insertion of measurement probes into the generated code. The software inserts measurement probes for an atomic subsystem only if you set the Function packaging field (on the Code Generation tab of the Function Block Parameters dialog box) to either Nonreusable function or Reusable function. If the field is set to Auto, then the insertion of probes depends on the packaging choice that results from the Auto setting. If the field is set to Inline, the software does not insert probes.

Note

In the generated code, the software wraps each function call with measurement probes except when:

The call site cannot be wrapped because of expression folding (see Minimize Computations and Storage for Intermediate Results at Block Outputs).
The call site is located in the shared utility code (see Generate Shared Utility Code).

To generate function execution times for model reference hierarchies:

In the top model, open the Configuration Parameters dialog box, and select the Code Generation > Verification pane.
Select the Measure task execution time check box
For each Model block that you want to profile, specify Measure function execution times only at the reference level for which you require function execution times.

For example, consider a top model that has Model block A, which in turn contains Model block B.

In top model, a model block references model A, which has a model block that references model B.

If you want to generate execution times for functions from model B, select Measure task execution time for the top model and specify Measure function execution times for model B.

These parameters of the top model override the corresponding parameters of referenced models:

Measure task execution time. If you disable this parameter for the top model, you also disable function profiling for referenced models.
Workspace variable
Save options

You can use the Code Profile Analyzer to configure and validate profiling settings for a model hierarchy. For more information, see Configure Profiling in Model Hierarchy.

Control Profiling of a Block

To control code execution profiling for a block in a model, for example, a subsystem block, use the CodeProfilingOverride block parameter:

In the Simulink Editor, select the block.
In the Command Window, run:
```
set_param(gcb, 'CodeProfilingOverride', blockParameterValue)
```
Use one of these values for blockParameterValue:
- 'off' –– Disables profiling for the block.
- 'on' –– Enables profiling for the block if profiling is enabled for the parent model.
- 'inherit' (default) –– Applies profiling settings of parent block.

Changing the block profiling configuration does not cause the regeneration of production code.

If your top model has a PIL block, the execution profiling settings that apply to the PIL block are the settings from the original model that you used to create the PIL block. See Simulation with Subsystem Blocks. You cannot use CodeProfilingOverride to control profiling for a PIL block.