Speed up a simulation by accelerating the initialization phase, using these techniques.

Complex graphics and large images take a long time to load and render. Masked blocks that contain such images can make your model less responsive. Where possible, remove complex drawings and images from masked blocks.

If you want to keep the image, replace it with a smaller, low-resolution
version. Use mask editor and edit the icon drawing commands to keep
the image that is loaded by the call to `image()`

.

For more information on mask editor, see Mask Editor Overview.

When you open or update a model, Simulink^{®} runs the mask
initialization code. If your model contains complicated mask initialization
commands that contain many calls to `set_param`

,
consolidate consecutive calls into a single call with multiple argument
pairs. Consolidating the calls can reduce the overhead associated
with these function calls.

To learn more, see Mask Callback Code.

If you use MATLAB^{®} scripts to load and initialize data,
you can improve performance by loading MAT-files instead. The data
in a MAT-file is in binary and can be more difficult to work with
than a script. However, the load operation typically initializes data
more quickly than the equivalent MATLAB script.

For more information, see MAT-Files for Signal Data.

In general, the more interactive a model is, the longer it takes to simulate. Use these techniques to reduce the interactivity of your model.

Some enabled diagnostic features can slow simulations considerably. Consider disabling them in
the model configuration parameters **Diagnostics**
pane.

**Note**

Running **Array bounds exceeded** and **Solver
data inconsistency** can slow down model runtime performance.
For more information, see Array bounds exceeded and Solver data inconsistency.

After verifying that your MATLAB code works correctly,
disable these checks in the model configuration parameters **Simulation
Target** pane.

**Enable debugging/animation****Detect wrap on overflow (with debugging)****Echo expressions without semicolons**

For more information, see Model Configuration Parameters: Simulation Target.

If your simulation involves low-level MATLAB matrix operations, use the Basic Linear Algebra Subprograms (BLAS) libraries to make use of highly optimized external linear algebra routines.

By default, Stateflow^{®} charts highlight the current active
states in a model and animate the state transitions that take place
as the model simulates. This feature is useful for debugging, but
it slows the simulation.

To accelerate simulations, either close all Stateflow charts or disable the animation. Similarly, consider disabling animation or reducing scene fidelity when you use:

Simulink 3D Animation™

Simscape™ Multibody™ visualization

FlightGear

Any other 3D animation package

To learn more, see Speed Up Simulation (Stateflow).

If your model contains a scope viewer that displays a high rate of logging and you cannot remove the scope, adjust the viewer properties to trade off fidelity for rendering speed.

However, when you use decimation to reduce the number of plotted data points, you can miss short transients and other phenomena that you can see with more data points. To have more precise control over enabling visualizations, place viewers in enabled subsystems.

For more information, see Scope Viewer.

Use these techniques to improve simulation performance by simplifying a model without sacrificing fidelity.

Replace a complex subsystem with one of these alternatives:

A linear or nonlinear dynamic model that was created from measured input-output data using the System Identification Toolbox™.

A high-fidelity, nonlinear statistical model that was created using the Model-Based Calibration Toolbox™.

A linear model that was created using Simulink Control Design™.

A lookup table. For more information, see A lookup table.

You can maintain both representations of the subsystem in a library and use variant subsystems to manage them. Depending on the model, you can make this replacement without affecting the overall result. For more information, see Optimize Generated Code for Lookup Table Blocks.

When you reduce the number of blocks in your model, fewer blocks require updates during simulations and simulation is faster.

Vectorization is one way to reduce your block count. For example, if you have several parallel signals that undergo a similar set of computations, try to combine them into a vector using a Mux block and perform a single computation.

You can also enable the

**Block Reduction**parameter in the**Configuration Parameters**dialog.

In frame-based processing, Simulink processes samples in batches instead of one at a time. If a model includes an analog-to-digital converter, for example, you can collect output samples in a buffer. Process the buffer in a single operation, such as a fast Fourier transform. Processing data in chunks this way reduces the number of times that the simulation needs to invoke blocks in your model.

In general, the scheduling overhead decreases as frame size increases. However, larger frames consume more memory, and memory limitations can adversely affect the performance of complex models. Experiment with different frame sizes to find one that maximizes the performance benefit of frame-based processing without causing memory issues.

Simulink provides a comprehensive library of solvers, including fixed-step and variable-step solvers, to handle stiff and nonstiff systems. Each solver determines the time of the next simulation step. A solver applies a numerical method to solve ordinary differential equations that represent the model.

The solver you choose and the solver options you select can affect simulation speed. Select and configure a solver that helps boost the performance of your model using these criteria. For more information, see Choose a Solver.

A stiff system has continuous dynamics that vary slowly and quickly. Implicit solvers are particularly useful for stiff problems. Explicit solvers are better suited for nonstiff systems. Using an explicit solver to solve a stiff system can lead to incorrect results. If a nonstiff solver uses a very small step size to solve a model, this is a sign that your system is stiff.

When you are deciding between using a variable-step or fixed-step solver, keep in mind the step size and dynamics of your model. Select a solver that uses time steps to capture only the dynamics that are important to you. Choose a solver that performs only the calculations needed to work out the next time step.

You use fixed-step solvers when the step size is less than or equal to the fundamental sample time of the model. With a variable-step solver, the step size can vary because variable-step solvers dynamically adjust the step size. As a result, the step size for some time steps is larger than the fundamental sample time, reducing the number of steps required to complete the simulation. In general, simulations with variable-step solvers run faster than those that run with fixed-step solvers.

Choose a fixed-step solver when the fundamental sample time of your model is equal to one of the sample rates. Choose a variable-step solver when the fundamental sample time of your model is less than the fastest sample rate. You can also use variable-step solvers to capture continuous dynamics.

When you decrease the solver order, you reduce the number of calculations that Simulink performs to determine state outputs, which improves simulation speed. However, the results become less accurate as the solver order decreases. Choose the lowest solver order that produces results with acceptable accuracy.

Increasing the solver step size or error tolerance usually increases simulation speed at the expense of accuracy. Make these changes with care because they can cause Simulink to miss potentially important dynamics during simulations.

Variable-step solvers dynamically adjust the step size, increasing it when a variable changes slowly and decreasing it when a variable changes rapidly. This behavior causes the solver to take many small steps near a discontinuity because this is when a variable changes rapidly. Accuracy improves, but often at the expense of long simulation times.

To avoid the small time steps and long simulations associated with these situations, Simulink uses zero-crossing detection to locate such discontinuities accurately. For systems that exhibit frequent fluctuations between modes of operation—a phenomenon known as chattering—this zero-crossing detection can have the opposite effect and thus slow down simulations. In these situations, you can disable zero-crossing detection to improve performance.

You can enable or disable zero-crossing detection for specific blocks in a model. To improve performance, consider disabling zero-crossing detection for blocks that do not affect the accuracy of the simulation.

For more information, see Zero-Crossing Detection.

In the classic workflow, a Simulink model simulates repeatedly for different inputs, boundary conditions, and operating conditions. In many situations, these simulations share a common startup phase in which the model transitions from the initial state to another state. For example, you can bring an electric motor up to speed before you test various control sequences.

Using `SimState`

, you can save the simulation
state at the end of the startup phase and then restore it for use
as the initial state for future simulations. This technique does not
improve simulation speed, but it can reduce total simulation time
for consecutive runs because the startup phase needs to be simulated
only once.

See Save and Restore Simulation Operating Point for more information.