8.3 Space Efficiency and Speed Efficiency

Table 8.1: Trade-offs between SVM and SCC

Tool	Achieve	Sacrifice
SVM	functionality and extensibility	space and speed
SCC	speed	space, modularity and functionality

Several aspects and concerns affect the design of SVM and SCC (Table 8.1). There are different emphases of these tools:

• SVM sacrifices space and speed to achieve functionality and extensibility. Here, space refers to the memory space required for a simulation. Because SVM is a simulator, speed and space usage is not the most important. However, it must provide a suitable experimental platform for a complete DCharts syntax and semantics. It must also be extensible so that new features can be easily added to the simulator, as DCharts are improved over time.

• SCC sacrifices space, modularity and functionality for speed. The purpose of code synthesis is to produce highly efficient code that can be used in practical applications. Hence, speed becomes the most important factor. SCC guarantees high performance for most of the implemented features, but sacrifices the features that are not practical, or warns the users about the implemented but inefficient ones. Modularity is not important either. When a model is transformed into Java code, it does not tend to change any more. The code for different DCharts features is usually mixed in an uninterpretable way to achieve better performance. For example, the model is flattened and its hierarchy information is encoded in its transitions. The code to fire transitions and to change the state of the model is optimized with static state properties such as default states, history and orthogonal components.

The design of SCC reflects the above concerns. The numbering of states and events reduces string comparison to integer comparison. Tables are statically generated, which records the parent-children relations and leaf states.

However, history still requires complex computation at run-time. This is because the behavior of models with history is statically unpredictable. For this reason, the use of history (whether it is common history or deep history) is discouraged, if the designer intends to synthesize really efficient code for his/her model.