Initially, whenModel1is active, costs of strategies represented by Figures 7.7(a) and 7.7(b) are 8 and 9, respectively, thus, the first strategy is selected for execution. On the other hand, when the model has been evolved into Model2 by applying some other rules, a new situation appears, since costs of strategies represented by Figures 7.7(c) and 7.7(d) are now 21 and 12, respectively. As a result, the pattern matching engine executes the second strategy forModel2.
Note that this behaviour is not surprising as the first and second strategy have been prepared at compile-time in such a way that corresponding search plans are optimized for typical modelsModel1
andModel2, respectively.
7.5.2 Run-time tasks in EJB3-based adaptive pattern matching
We present how run-time tasks of an adaptive EJB3-based pattern matching engine (including tasks in theAdaptandExecphases of Fig. 7.1) can be implemented.
For each LHS pattern and adornment combination, a stateless session bean is prepared, which maintains references to the available, compiled pattern matching strategies. The stateless session bean implements thematch()method of theIPatternMatcherinterface as presented by Listing 7.3.
1 boolean match(Matching m) {
2 // Finding the cheapest strategy
3 Strategy cheapestStrategy = strategies.get(0);
4 double cheapestCost = cheapestStrategy.cost();
5 for (int i=1; i < strategies.size(); i++) {
6 Strategy currentStrategy = strategies.get(i);
7 double currentCost = currentStrategy.cost();
8 if (currentCost < cheapestCost) {
9 cheapestCost = currentCost;
10 cheapestStrategy = currentStrategy;
11 }
12 }
13 // Executing the cheapest strategy
14 return cheapestStrategy.match(m);
15 }
Listing 7.3: Implementation of thematch()method
The adaptation phaseAdaptis reflected by Lines 2–12. This code fragment iterates over all pattern matching strategies (Lines 5–12), by also maintaining references to strategies (Line 6) and their corre-sponding costs (Line 7), and selects the cheapest strategy, which is later executed (in theExecphase) in Lines 13–14.
By using container managed transactions, thematch()method also provides the transaction con-text for pattern matching execution. This feature of the application server enables the parallel execution of a given rule without any modification in the pattern matching code.
7.6 Performance evaluation
In this section, the performance of the adaptive graph pattern matching technique and different EJB3-based transformation plugins is evaluated.
120 CHAPTER 7. ADAPTIVE GRAPH TRANSFORMATION
Performance analysis of the adaptive pattern matching approach. The quantitative performance analysis of the adaptive graph pattern matching approach has been deferred for years due to the lack of statistics support in underlying model repositories at the time of the development.
A recent report [12] examined the correlation of search plan costs and execution times in adaptive pattern matching approaches. More specifically, the authors focused on the quality of heuristics by checking whether low cost search plans also have short execution times.
In these experiments, three cost models have been examined and compared, namely, the heuristics proposed in this chapter, the highly similar original approach in GrGen [10, 11], and a new heuristics called Backtracking Lookup [12], which introduced costs for edge lookups as well. All search plans were generated for a given rule precondition according to each heuristics while measuring the execution time for each search plan. The exact experiment settings can be found in [12].
Based on the plots prepared for these measurements, the following statements could be made.
• On the Mutex STS test set of Sec. 5.3.1, all the heuristics (including the one presented in the current chapter) always produced the optimal search plan.
• The execution times of the possible search plans have a rather unbalanced distribution, so there is room for optimizations, which is confirmed by the development of the new Backtracking Lookup heuristics, which provided better search plans on an example originating from the compiler con-struction domain.
The memory consumption of graph transformation tools (including approaches using the adaptive pattern matching technique) has been assessed at the AGTIVE Tool Contest on the Sierpi´nski triangle benchmark example [133]. Note that this benchmark can only provide a inaccurate view on the perfor-mance of the adaptive technique as this approach should not have a significant influence on memory usage by its nature.
Quantitative performance analysis of transformation plugins. The performance of EJB3-based transformation plugins (namely, the portable EJB QL based solution of Sec. 6.6 and the approach of Sections 7.4.2 and 7.5.2 that operates on EJB3 entity beans) is evaluated by carrying out experiments on the object-relational mapping benchmark example, which has already been introduced in Sec. 5.4. Our main goal was to assess the overhead caused by an application server and the underlying persistence layer (including the relational database) required to run EJB3 applications. Therefore, after fixing a common pattern matching strategy, we executed measurements on three different approaches. In the first case, the transformation is performed on models consisting of in-memory Java objects without using an application server and a database. In the other two approaches, the transformation runs in an application server as an Enterprise Java Bean, and the corresponding instance model consists of entity beans, which are stored in the underlying database. The second approach executes pattern matching imperatively in the way described by thematch()method in Sec. 7.4.2, while the third approach uses EJB QL queries in the pattern matching phase as presented in Sec. 6.6.
Since the optimization strategy ofparallel rule executionis expected to have a significant impact on the run-time performance of all these approaches, its effect has also been observed during the mea-surements. Two test cases have been identified by switching this tool feature on and off. For each test case, the parameterN, which denotes the number of classes in the run, was fixed to 10, 30, 50, and 100.
For our measurements, we used a 1500 MHz Pentium machine with 768 MB RAM and a Linux operating system with kernel version 2.6.7 running Java SDK 1.5, JBoss application server version
7.6. PERFORMANCE EVALUATION 121
4.2.1, Hibernate object-relational persistence layer version 3.2.4, and MySQL relational database ver-sion 4.1.7. The execution time results are shown in Table 7.1.
Class Model TS
size length match update match update match update
# # # msec msec msec msec msec msec
10 1342 146 0.01 0.03 117.31 13.91 7.14 125.87 30 12422 1336 0.01 0.03 960.87 49.50 14.34 978.22
50 34702 3726 0.05 0.06 28.07 2767.67
100 139402 14951 0.01 0.01
10 1342 146 0.01 0.03 23.38 10.19 2.83 18.17 30 12422 1336 0.01 0.01 41.07 6.33 2.66 38.97 50 34702 3726 0.01 0.01 71.31 16.49 2.93 58.95 100 139402 14951 0.01 0.01 123.45 13.04 3.40 115.48 10 1342 146 0.04 0.03 100.95 10.98 8.59 68.82 30 12422 1336 0.03 0.01 796.00 25.84 7.73 478.06
50 34702 3726 0.06 0.01 9.32 1364.83
100 139402 14951 0.36 0.01
10 1342 146 0.01 0.03 7.94 5.39 2.30 5.41 30 12422 1336 0.01 0.03 7.54 5.91 2.25 5.34 50 34702 3726 0.01 0.02 10.79 5.29 2.30 7.71 100 139402 14951 0.01 0.04 24.14 4.72 2.32 15.48 10 1342 146 1.56 0.04 319.02 384.45 11.14 67.67 30 12422 1336 0.39 0.01 2253.24 3387.53 12.91 148.55
50 34702 3726 1.20 0.01 19.54 229.79
100 139402 14951 5.11 0.01
10 1342 146 0.04 0.03 16.58 11.79 4.11 11.82 30 12422 1336 0.02 0.01 51.10 43.32 4.08 34.47 50 34702 3726 0.01 0.01 134.87 118.27 3.89 69.38 100 139402 14951 0.01 0.01 402.06 358.67 3.95 215.93 OFF
Table 7.1: Performance evaluation of EJB3 plugins
The head of a row (i.e., the first two columns) shows the name of the rule and the optimization strategy settings for the single tool feature (i.e., parallel rule execution) on which the average is cal-culated. (Note that a rule is executed several times in a run.) The third column (Class) depicts the number of classes in the run, which is, in turn, the runtime parameterN of the test case. The fourth and fifth columns show the concrete values for the model size and the transformation sequence length, respectively. Heads of the remaining columns unambiguously identify the approach having been used.
Values inmatchandupdatecolumns depict the average times needed for a single execution of a rule in the pattern matching and updating phase, respectively. Execution times were measured on a mi-crosecond scale, but a millisecond scale is used in Table 7.1 for presentation purposes. Light grey areas denote run-time failures due to exceeding the default limits of the application server on the number and size of transactions.
Our observations can be summarized as follows.
• General performance related observations.On a given model size, the pure Java solution runs three or four orders of magnitude faster than the enterprise applications during both the pattern matching and the updating phase. The slowness of enterprise applications is caused mainly by the overhead of disk-based storage, and transaction handling, and partially by the maintenance of database connections.
122 CHAPTER 7. ADAPTIVE GRAPH TRANSFORMATION
• Performance degradation caused by the different data structures used by the model repos-itory.There is a further factor, which causes a significant deceleration of enterprise applications during the updating phase and in case of large models. This originates from the fact that the most frequently applied model manipulation steps operate on different data structures. In this sense, the pure Java solution stores neighbouring objects in linked lists, to which new objects can be added in constant time, while the underlying relational database of application servers uses a tree-based data structure, in which additions can only be performed in logarithmic time.
• Unsuitable proxy and transaction handling mechanisms in Hibernate and JBoss. An unac-ceptably slow execution time and high resource demand have been detected in case of enterprise applications, which have been caused by the current version of the proxy mechanism of Hiber-nate and the transaction handling of JBoss.