A few days ago I happened to speak with a colleague about Simulink run-time performance, and we discussed various ideas for simulation speed-up. This topic is very important to MathWorks, as evidenced by a dedicated documentation section ^[1], newsletter articles (1 ^[2], 2 ^[3]), webinars (1 ^[4], 2 ^[5], 3 ^[6], 4 ^[7]) and multiple blog posts ^[8] on improving simulation performance using the Simulink product.
This blog covers mainly the Matlab core product and closely-related toolboxes. However, since the various suggestions for improving performance are spread across so many resources, I thought that it would be worthwhile to create a post listing all the suggestions in a single place. When faced with a slow simulation, it’s nice to know that there are so many available speed-up options, so I hope readers will find it useful. Note that these suggestions are in the large part fully documented and supported. The ideas are listed based on semantic relationship, and not by order of importance:

• Select Accelerator or Rapid Accelerator ^[9] simulation mode (also see here ^[10])
• Enable the options for Compiler optimization, automatic Block Reduction and others in the Optimization pane ^[11] of the Configuration Parameters window.
• Switch the Compiler optimization ^[12] from faster build to faster run.
• Disable the options ^[13] for debugging/animation support, overflow detection and echoing expressions without semicolons in the Simulation Target pane of the Configuration Parameters window. Note that overflow detection is important for fixed-point data so if your model includes FP data, keep this option enabled.
• Disable similar configuration options ^[14] in Stateflow’s Configuration Parameters window (which is similar but separate from the Simulink window).
• Keep Stateflow charts and Simulink blocks/models closed during simulation to prevent run-time updates (this relates to the animation feature, if enabled)
• Keep output scopes ^[15] closed during simulation run-time; open the scopes only after the simulation ends. If a scope must remain open in run-time, reduce the number of data points (via decimation, reduced time range and reduced number of plotted signals), increase the plotting refresh period, disable scope scrolling, remove data markers and legends, limit the history size, and use reduced fidelity in the viewer parameters. A similar recommendation applies to regular Matlab plots, by the way.
• Vectorize processing by combining multiple signals into a vector and applying the processing on the vector rather than on the separate signals.
• Sample data in batches ^[16] (rather than one-by-one) using frame-based processing (R2011b and newer ^[17]). This can speed up simulations by 10x or more, at the expense of just a little extra memory.
• Aggregate small blocks into larger ones.
• Load the model in memory ^[12] using load_system instead of open_system and simulate it using the sim command, then post process/display the outputs.
• Avoid ^[12] blocks that do not support code generation, since they would have to be run in slower interpreted mode.
• If your simulation does not use linear algebra (matrix arithmetic), disable BLAS library support in the Simulation Target pane. But if it does use it, then ensure that BLAS is enabled for optimal performance.
• Avoid ^[12] algebraic loops where possible.
• Avoid ^[12] Matlab S-Function and Interpreted Matlab Function blocks. Instead, use Matlab Function, System and C-MEX blocks.
   

  Note: IMHO, the naming of these blocks is quite confusing: Matlab Function refers to a subset of the Matlab language previously called Embedded Matlab that can be directly converted into C-code without requiring the Matlab run-time (MCR); this is basically the language subset used by the Matlab Coder Toolbox. Interpreted Matlab Function refers to the full Matlab functionality and requires the Matlab run-time (MCR) – it was previously called Matlab Function.

• Reduce, simplify or eliminate initialization and termination phases.
• Use the Mask Editor ^[18] to reduce block images resolution and size.
• Store configurations in loadable MAT files ^[19] rather than programmatically.
• Consolidate multiple set_param calls into a single call having several name / value pairs.
• Use a stronger platform (esp. increase the amount of memory).
• Limit or disable log output ^[20], and disk I/O in general.
• Use the sldiagnostics and slprofreport functions and the Simulink Profiler ^[21], to identify and eliminate simulation bottlenecks.
• Use the performanceadvisor function and the Simulink Model Performance Advisor ^[22] to automatically adjust model configurations for best performance (R2012b and newer ^[23]; also see this webinar ^[24]).
• Manually adjust model solver parameters for optimal performance, based on a-priori knowledge about the model behavior.
• Use a faster solver ^[25] that can still process the model. Different models may require different solvers to run optimally (also see here ^[26]).
• Tune solver parameters ^[27] (decrease solver order, increase step size and error tolerance) to improve solution convergence speed at the expense of some accuracy. One user reported ^[28] a 20x speedup by simply increasing the step-size.
• Prevent excessive zero-crossing ^[29] or disable zero-crossing detection (also see here ^[30] and here ^[31]).
• Use simpler models or models with reduced fidelity.
• Store the simulation state ^[32] at specific points, then load these states for repeated later simulations, thus saving the simulation time of the loaded portion.
• Run simulations in parallel ^[33] using Parallel Computing Toolbox (also see here ^[3], here ^[34] and here ^[35]). An easy way to do this ^[12] is to run the sim command within a parfor loop.
• Move some calculations ^[20] onto FPGA or GPU.
• Use a real-time system and set simulation speed to real-time (high priority).

Some additional ideas can be found in the blog posts and webinars mentioned in the hyperlinks at the top of this post. One of the newsletter articles concludes ^[2] with an example of how applying some of these techniques to a specific model resulted in reduced simulation time, from 453 down to 5 seconds.
I would like to take this opportunity to congratulate MathWorks on a job well done with Simulink’s Performance Advisor. I expect a variant of this tool to be available for regular Matlab m-code in some future Matlab release; it would blend in nicely with the existing mlint (Code Analyzer) tool.

Advanced Matlab Programming course – London 10-11 March, 2014

If this topic has piqued your interest, consider joining my Advanced Matlab Programming course ^[36] in London on 10-11 March, 2014. In this course/seminar I will explore numerous other ways by which we can improve Matlab’s performance and create professional code. This is a unique opportunity to take your Matlab skills to a higher level within a couple of days.

3 Comments To "Improving Simulink performance"

#1 Comment By Etienne On February 16, 2014 @ 13:27

#2 Comment By Yair Altman On February 16, 2014 @ 16:03

#3 Comment By Etienne On February 17, 2014 @ 14:17