The following is a collection of tips for how to avoid performance problems and bottlenecks when working with DevOps Model RealTime.
Eclipse-based applications like Model RealTime are built under the assumption that accesses to files in the installation and the workspace are fast. Such files are therefore accessed frequently with little caching. You should avoid putting the installation or workspace files in a location where file accesses are slow, for example on a network drive or in a ClearCase dynamic view. If the Model RealTime installation and workspace files are placed locally, performance is better.
By default, Model RealTime loads models incrementally on demand ("lazy loading"). This enables you to start working immediately after the tool has started, but it also leads to a small delay each time a new model is loaded, for example when expanding an element in the Project Explorer. To avoid these small delays, you might want to load all (or some of) the models in your workspace once, to benefit from the performance improvements you get by having the models loaded into memory. Read more about the Load UML Models command in the article Working with fragmented models.
By default, Model RealTime performs live validation of the models in your workspace as you edit them. The reason for the live validation is to detect problems and constraint violations as early as possible. However, this validation takes some time, especially if you have loaded big models into memory (for example using Load UML Models). You should configure Model RealTime to only run the live validations that you find useful. Read more about this here.
Most search features in Model RealTime, for example Find/Replace and Find NamedElement, make use of a model index. This search index is built incrementally when opening a workspace and importing projects into it or when creating new projects. By default the search index is stored in your workspace metadata. You should therefore avoid deleting your workspace too often, as this means the search index must be recreated in the new workspace. You can also consider to store the search index at a different location (for example near each project) and put them under source control. This can be useful for projects that are not often changed, since users then will have a pre-built index for them already.
The workspace metadata contains several caches that are used to make Model RealTime faster. The search index is one example, but there is also other cached data. When you delete a workspace and start over using a new workspace, all such data is lost and some operations are slower until the caches have been recreated. In general, it is recommended to keep using a workspace and only delete it when necessary.
By using appropriate search settings, Model RealTime can perform searches more quickly. Always have a search limit set to avoid finding too many elements with the search. Model RealTime, by default, uses a search limit everywhere and it is recommended to not turn it off or raise it to a very high value. Reporting a very high number of search result elements can make the Model RealTime user interface unresponsive. It is anyway not useful to have too many elements in the search result.
Another way to limit the number of found elements and hence the time it takes to perform the search is to use an appropriate search scope. For example, if you know that the elements you are looking for are contained in a certain project, set the search scope to that project rather than the entire workspace.
With numerous and large models within a workspace, you can sometimes get many problems reported in the Problems view. By default, the Problems view shows all problems for all models in the entire workspace. Besides not being useful, so many problems might also lead to performance problems when working with the Problems view. To avoid this, configure the Problems view to only show the problems you are currently interested in. For example, use the option Show - Errors/Warnings on Selection in the view menu, to only show problems that relate to the selected element. Read more about the Problems view here.
Model RealTime supports displaying and editing rich text in diagrams and the Properties view. By default, this support is turned on, which means that the rich text editor is instantiated every so often when you are working in the user interface. This takes some time, especially on systems with a large number of fonts installed. It is recommended to turn off the support for rich text, unless you need it. The preference to disable is Modeling - Text - Enable rich text editor. Read more in the article Rich text.
Diagram filters enable you to control how much information is displayed in diagrams. The more information is shown in a diagram, the more time it takes to render it when it is opened. Do not show unnecessary information in diagrams. Read more about the available preferences in Diagram Filtering Preferences.
Traditionally, external self-transitions have been the mechanism to use when you need to execute some code while remaining in the same state in a state machine. However, if you really want to remain in the same state without first leaving it and then entering it again, you should use an internal transition for this purpose. Internal transitions are shown in a compartment of a composite state rather than as transition lines on the edge of a state. Your diagram contains fewer lines if you convert external self-transitions to internal transitions, and the diagram opens faster. Also, generated C++ code can be more efficient when using internal transitions, since there is no need to exit and enter the state. There is a command in the context menu of a state (Refactor - Convert All External Self-Transitions to Internal Transitions) or an external self-transition (Refactor - Convert to Internal Transition), which converts existing external self-transitions to internal transitions. The command warns you if the conversion leads to a changed run-time behavior for the model. If it does not, you are encouraged to convert the external self-transitions to internal transitions.
The preference RealTime Development - Diagrams - Reuse editor when performing Go Inside/Outside, is turned off by default. This means that when navigating in state machine and composite structure hierarchies by means of the Go Inside and Go Outside commands, the target diagram (i.e. the diagram you navigate to) is opened in a new editor. From a performance point of view, it is recommended to keep this preference turned off, since it makes navigation faster when the target diagram is already open in an editor. Navigation is made by simply activating that specific editor. The reason for enabling that preference, is that editors are reused when navigating from one diagram to another, and avoid opening too many editors while navigating in the model. When the editor is being reused, the latest target diagram opens in the open editor and the previous diagram is replaced in that editor. To return to the earlier diagram, you must reopen and re-render it, which causes a performance impact.
The C++ editor scalability preferences enable you to control when the CDT editor enters scalability mode, which is a mode used to improve performance when working with big C++ files. Read more about these preferences in CDT editor scalability settings.
For big C++ projects, CDT indexing can take a lot of time. You can turn off indexing using a preference (C/C++ - Indexer - Enable indexer), but many features of CDT, such as navigation and code completion, are then not available. There are, however, several other preferences in the same preference page that enable you to configure the CDT indexer, which might have a big impact on performance. Read more about these preferences here.
By default, Model RealTime generates recursive make files, i.e. make files that recursively invoke the make command on other "sub make files". If you use a parallelized build system, which supports the distribution of build tasks on different machines in a build cluster, you might find that the processing of the many make files becomes a bottleneck in the build process. You can set the preference RealTime Development - Build/Transformations - Type of Generated Make File to "Inclusive," which results in make files that include other make files instead. The build of a transformation configuration then results in a single invocation of the make command, which might make the build faster.
There are many settings in eclipse.ini that can be set to improve the performance of Model RealTime. Read more about this topic here.
Even though Model RealTime provides CTD/Codan functionality, projects generated by Model RealTime do not have full information for Codan to run successfully - this is by design. The reason is that the CDT indexer has a dramatic impact on tool performance and is not suitable for frequent project generations. It is recommended to disable code analysis to prevent Model RealTime from hanging; it can not function correctly for generated projects. Take this into account when evaluating CDT extensions. To turn off Codan, disable all preferences in C/C++ - Code Analysis.