Truth Tables to Binary Decision Diagrams in Modern ATL

(1)

(2)

2 Optimizations

In order to optimize the TT2BDD transformation, we used the EMFTVM built-in profiler. This lead us to the three following optimizations:

• Leveraging helper attributes caching. ATL provides two kinds of helpers: helper operations, and helper attributes. Helper attributes are basically similar to parameterless helper operations with a significant performance-related difference: their result is cached. Therefore, multiple accesses do not result in multiple computations. The getTree helper operation was thus changed into a tree helper attribute. With a lower performance impact, the getNode helper operation was also changed into a node helper attribute.

• Applying the object indexing pattern

⁵

. This pattern uses a Map in order to avoid expensive lookups that can be precomputed. A typical example is the navigation of missing opposite references.

• Leveraging Maps. In the getPartition helper operations, the original row-accessing code is quadratic: a use of the exists iterator in the body of a select iterator. We instead compute two Maps: one for each of the possible true and false values. These Maps are indexed by ports. Moreover, these Maps are computed in helper attributes, and are therefore cached and computed only once per context. Because EMFTVM uses a HashMap to implement Maps, the resulting code has a linear time complexity.

Another optimization was performed in the transformation launcher: module loading code was moved into the initialization phase.

The optimizations were applied after repeated measurements with the ATL/EMFTVM profiler. This profiler can be enabled by checking the ”Display Profiling Data” box in the Eclipse Run Configuration dialog. Listing 6 in Appendix shows the output of running the ATL reference solution (before any optimization) against the

“GeneratedI8O2Seed68.ttmodel”. Typically, the maximum gains can be achieved by addressing the top lines of the profiler output, in this case the getPartition and getTree helper operations. The top line of the profiler output amounts to 21.45% of the total measured runtime of the transformation. It represents a qualified portion of the getPartition helper operation: the “@0@0” qualifier designates the first closure within the first closure of the getPartition helper body, which is invoked 41811968 times.

Listing 1 shows the getPartition helper operation. The first closure within the first closure is the body of the exists iterator within the select iterator (line 9). In this case, the fact that so much runtime is spent here is due to the high amount of invocations.

1

helper def

:

2 g e t P a r t i t i o n ( r o w s : S e q u e n c e ( TT ! Row ) , p o r t : TT ! P o r t )

3 : T u p l e T y p e ( z e r o P a r t : S e q u e n c e ( TT ! Row ) , o n e P a r t : S e q u e n c e ( TT ! Row ) ) =

4

5 - - S e l e c t t h e r o w s f o r w h i c h t h e p o r t is f a l s e

6

let

_ z e r o P a r t : S e q u e n c e ( TT ! Row ) =

7 rows - > s e l e c t ( r |

8 r . cells - > e x i s t s ( c |

9 c . p o r t = p o r t

and

c . v a l u e = f a l s e

10 )

11 )

in

12

13 - - S e l e c t t h e r o w s f o r w h i c h t h e p o r t is t r u e

14

let

_ o n e P a r t : S e q u e n c e ( TT ! Row ) =

15 rows - > s e l e c t ( r |

16 r . cells - > e x i s t s ( c |

17 c . p o r t = p o r t

and

c . v a l u e = t r u e

18 )

19 )

in

20

21 - - B u i l d t h e r e s u l t i n g t u p l e

22 T u p l e {

23 z e r o P a r t = _ z e r o P a r t ,

24 o n e P a r t = _ o n e P a r t

25 };

Listing 1: The getPartition helper operation

Instead of trying to optimize directly at this level, we first trace back where the getPartition helper is invoked: it is invoked only from within the getTree helper operation. The getTree helper operation is also

5https://wiki.eclipse.org/ATL/Design_Patterns#Object_indexing

(3)

responsible for a large portion of the transformation runtime: the main helper body is responsible for 8.50% of the measured runtime, and is invoked 718080 times (line 7 of Listing 6). There are two getTree helper operations:

one with input parameters, and one without. The one with input parameters invokes itself recursively, and the one without input parameters only invokes the one with parameters.

Listing 2 shows the getTree helper without input parameters. This helper operation is invoked on the TT!TruthTable context, of which there is always one instance in an input model. Yet, in 6, line 16, it shows up with 2816 invocations. If we convert this helper operation into a helper attribute, its body will be executed only once for each TT!TruthTable instance, and any subsequent invocations will be retrieved from cache.

1

helper context

TT ! T r u t h T a b l e

def

:

2 g e t T r e e ()

3 : T u p l e T y p e ( c e l l : TT ! C e l l , z e r o S u b t r e e : O c l A n y , o n e S u b t r e e : O c l A n y ) =

4 t h i s M o d u l e . g e t T r e e ( s e l f . rows , s e l f . ports - > s e l e c t ( p | p . o c l I s K i n d O f ( TT ! I n p u t P o r t ) ) ) ;

Listing 2: The getTree helper operation

Commit c1208ae

⁶

contains the first performance optimization: convert the parameterless getTree helper operation into the tree helper attribute. Listing 7 shows the profiler output after applying this optimization.

There is only one invocation of the tree helper attribute body on line 21. As a result, the amount of runtime spent in the remaining getTree helper operation and the getPartition helper operation has also been drastically reduced. The total runtime has been reduced from 69.832018 seconds to 0.703755 seconds.

Now, the top line in the profiler output points to the findCell helper operation. findCell is invoked by the getNode helper operation. getNode is also a parameterless helper operation, which can easily be converted to a helper attribute to reduce the amount of times its body is invoked. Commit dd9b976

⁷

does just that, and Listing 8 shows the profiler output after applying this optimization. The 2815 invocations of getNode on line 10 of Listing 7 have become 2560 invocations of the node helper attribute on line 10 of Listing 8. Not a significant improvement this time, but it has been achieved with very little effort.

That leaves the findCell helper at the top of the list with 620415 invocations, responsible for 87.77% of the measured runtime. Listing 3 shows this findCell helper. Its purpose is to find the corresponding tree node for a given TT cell. Ideally, it is invoked once per cell, but the representation of the in-memory tree structure makes that we cannot simply convert this operation into an attribute. We therefore resort to the object indexing pattern, which computes a Map of cells to their tree nodes.

1

helper def

:

2 f i n d C e l l ( c e l l : TT ! Cell , t r e e : T u p l e T y p e ( c e l l : TT ! Cell , z e r o S u b t r e e : OclAny , o n e S u b t r e e : O c l A n y ))

3 : T u p l e T y p e ( c e l l : TT ! C e l l , z e r o S u b t r e e : O c l A n y , o n e S u b t r e e : O c l A n y ) =

4

5

i f

t r e e . c e l l = c e l l

then

6 t r e e

7

else i f

t r e e . z e r o S u b t r e e . o c l I s K i n d O f ( TT ! Row )

then

8

i f

t r e e . o n e S u b t r e e . o c l I s K i n d O f ( TT ! Row )

then

9 - - B o t h s u b t r e e s a r e l e a f n o d e s

10 O c l U n d e f i n e d

11

else

12 - - O n l y t h e s u b t r e e 1 is n o t a l e a f

13 t h i s M o d u l e . f i n d C e l l ( cell , t r e e . o n e S u b t r e e )

14

endif

15

else

16

let

t r y I n Z e r o : O c l A n y = t h i s M o d u l e . f i n d C e l l ( cell , t r e e . z e r o S u b t r e e )

in

17

i f

then

19 t r y I n Z e r o

20

else i f

t r y I n Z e r o . o c l I s U n d e f i n e d ()

then

21 - - B o t h s u b t r e e s a r e non - l e a v e s , b u t s u b t r e e 0 d i d n o t p r o d u c e a n y r e s u l t s

22 t h i s M o d u l e . f i n d C e l l ( cell , t r e e . o n e S u b t r e e )

23

else

24 - - B o t h s u b t r e e s a r e non - l e a v e s , a n d s u b t r e e 0 h a s p r o d u c e d r e s u l t s

25 t r y I n Z e r o

26

endif endif

27

endif endif

;

Listing 3: The findCell helper operation

6https://github.com/dwagelaar/ttc2019-tt2bdd/commit/c1208aebc2e3a89601411b66c83446f555dd9fe6

7https://github.com/dwagelaar/ttc2019-tt2bdd/commit/dd9b976fb79d95bb11748bb96d5e8326fa43feae

(4)

Listing 4 shows the new nodesByCell helper attribute, with its companion collectAllNodes helper operation.

nodesByCell uses the mappedBySingle built-in helper operation introduced by EMFTVM to convert a list of tree nodes into a map of cells to nodes. Whereas it is trivial to find the accompanying cell for a given tree node, there is no direct way to find the tree node for a given cell. mappedBySingle enables one to quickly reverse navigate a given EMF EReference. The collectAllNodes helper operation serves to flatten the tree of nodes into a Sequence of nodes, such that it can be consumed by mappedBySingle.

1

helper context

TT ! T r u t h T a b l e

def

:

2 n o d e s B y C e l l

3 : Map ( TT ! Cell , T u p l e T y p e ( c e l l : TT ! Cell , z e r o S u b t r e e : OclAny , o n e S u b t r e e : O c l A n y )) =

4

5 t h i s M o d u l e . c o l l e c t A l l N o d e s ( s e l f . t r e e )

6 - > m a p p e d B y S i n g l e ( n o d e | n o d e . c e l l );

7

8

helper def

:

9 c o l l e c t A l l N o d e s ( t r e e : T u p l e T y p e ( c e l l : TT ! Cell , z e r o S u b t r e e : OclAny , o n e S u b t r e e : O c l A n y ))

10 : S e q u e n c e ( T u p l e T y p e ( c e l l : TT ! C e l l , z e r o S u b t r e e : O c l A n y , o n e S u b t r e e : O c l A n y )) =

11

12

i f

t r e e . z e r o S u b t r e e . o c l I s K i n d O f ( TT ! Row )

then

13

i f

then

14 - - B o t h s u b t r e e s a r e l e a f n o d e s

15 S e q u e n c e {}

16

else

18 t h i s M o d u l e . c o l l e c t A l l N o d e s ( t r e e . o n e S u b t r e e )

19

endif

20

else

21

i f

then

23 t h i s M o d u l e . c o l l e c t A l l N o d e s ( t r e e . z e r o S u b t r e e )

24

else

25 - - B o t h s u b t r e e s a r e non - l e a v e s

26 t h i s M o d u l e . c o l l e c t A l l N o d e s ( t r e e . z e r o S u b t r e e ) - > u n i o n (

27 t h i s M o d u l e . c o l l e c t A l l N o d e s ( t r e e . o n e S u b t r e e ))

28

endif

29

endif

30 - > p r e p e n d ( t r e e );

Listing 4: The findCell helper operation

Listing 9 shows the profiler output after applying the object indexing pattern: total measured runtime has been reduced from 0.670487 seconds to 0.086927 seconds, which is significant. The remaining top entries in the profiling output are getPartition and getTree (and contained closures thereof). We will focus on the top entry (line 3), which is the first closure within the first closure of getPartition. Listing 1 shows the getPartition helper operation, our first example, of which line 9 represents the first closure within the first closure. Along with line 5 of the profiler output – the first closure within the second closure (Listing 1 line 17) – this closure stands out through its high amount of invocations (14848), and resulting percentage of the total measured runtime (12.37%).

In commit 6fcd025

⁸

, we again apply the object indexing pattern to quickly retrieve cells by their port, also prefiltered by their value (true or false). Listing 5 shows the improved version of the getPartition helper. The double nesting of closures has been eliminated, and instead two Maps are created for each row, containing the true cells mapped by their port and the false cells by their port.

Listing 10 shows the profiler output after this optimization. The remaining entries in this output show little opportunity for further optimization: either their percentage in the total measured runtime is very low, or the number of invocations is very low (i.e. not higher than the amount of model elements). As such, we have decided not to optimize further at this point. Overall, we have achieved a speedup of 912 times.

3 Conclusion

The state of the art EMFTVM was able to run an old ATL transformation. Although, it cannot automatically optimize it, its built-in profiler makes it possible to quickly spot performance bottlenecks and fix them by making relatively simple changes such as turning parameterless helper operations into helper attributes, or applying well- documented patterns such as the object indexing pattern. This paper has also illustrated how to interpret the profiler output, and how to use it in order to apply performance optimizations.

8https://github.com/dwagelaar/ttc2019-tt2bdd/commit/6fcd025952451461a2affb415a75c54f90f3562b

(5)

1

helper def

:

2 g e t P a r t i t i o n ( r o w s : S e q u e n c e ( TT ! Row ) , p o r t : TT ! P o r t )

3 : T u p l e T y p e ( z e r o P a r t : S e q u e n c e ( TT ! Row ) , o n e P a r t : S e q u e n c e ( TT ! Row ) ) =

4

5 - - S e l e c t t h e r o w s f o r w h i c h t h e p o r t is f a l s e

6

let

_ z e r o P a r t : S e q u e n c e ( TT ! Row ) =

7 rows - > r e j e c t ( r |

8 r . f a l s e C e l l s B y P o r t . get ( p o r t ). o c l I s U n d e f i n e d ()

9 )

in

10

11 - - S e l e c t t h e r o w s f o r w h i c h t h e p o r t is t r u e

12

let

_ o n e P a r t : S e q u e n c e ( TT ! Row ) =

13 rows - > r e j e c t ( r |

14 r . t r u e C e l l s B y P o r t . get ( p o r t ). o c l I s U n d e f i n e d ()

15 )

in

16

17 - - B u i l d t h e r e s u l t i n g t u p l e

18 T u p l e {

19 z e r o P a r t = _ z e r o P a r t ,

20 o n e P a r t = _ o n e P a r t

21 };

22

23

helper context

TT ! Row

def

: t r u e C e l l s B y P o r t : Map ( TT ! Port , Set ( TT ! C e l l )) =

24 s e l f . c e l l s

25 - > s e l e c t ( c | c . v a l u e )

26 - > m a p p e d B y ( c | c . p o r t );

27

28

helper context

TT ! Row

def

: f a l s e C e l l s B y P o r t : Map ( TT ! Port , Set ( TT ! C e l l )) =

29 s e l f . c e l l s

30 - > r e j e c t ( c | c . v a l u e )

31 - > m a p p e d B y ( c | c . p o r t );

Listing 5: The improved getPartition helper operation

References

[GDH19] Antonio Garcia-Dominguez and Georg Hinkel. Truth Tables to Binary Decision Diagrams. In Antonio Garcia-Dominguez, Georg Hinkel, and Filip Krikava, editors, Proceedings of the 12th Transforma- tion Tool Contest, a part of the Software Technologies: Applications and Foundations (STAF 2019) federation of conferences, CEUR Workshop Proceedings. CEUR-WS.org, July 2019.

[Sav06] Guillaume Savaton. Truth Tables to Binary Decision Diagrams. ATL Transformations, https:

//www.eclipse.org/atl/atlTransformations/#TT2BDD, February 2006. Last accessed on 2019-05- 14. Archived on http://archive.is/HdoHM.

[WTCJ11] Dennis Wagelaar, Massimo Tisi, Jordi Cabot, and Fr´ ed´ eric Jouault. Towards a General Composition

Semantics for Rule-based Model Transformation. In Proceedings of the 14th International Confer-

ence on Model Driven Engineering Languages and Systems, MODELS’11, pages 623–637, Berlin,

Heidelberg, 2011. Springer-Verlag.

(6)

Appendix

1 D u r a t i o n ( sec .) D u r a t i o n (%) I n v o c a t i o n s O p e r a t i o n

2 1 4 , 9 7 4 6 0 7 21 ,45 4 1 8 1 1 9 6 8 s t a t i c E M F T V M ! E x e c E n v :: g e t P a r t i t i o n ( . . . ) : T u p l e @ 0 @ 0

3 1 4 , 9 4 2 5 6 5 21 ,40 4 1 8 1 1 9 6 8 s t a t i c E M F T V M ! E x e c E n v :: g e t P a r t i t i o n ( . . . ) : T u p l e @ 1 @ 0

4 6 , 4 0 2 9 4 4 9 ,17 5 7 6 7 1 6 8 s t a t i c E M F T V M ! E x e c E n v :: g e t P a r t i t i o n ( . . . ) : T u p l e @ 0

5 6 , 3 7 9 7 3 9 9 ,14 5 7 6 7 1 6 8 s t a t i c E M F T V M ! E x e c E n v :: g e t P a r t i t i o n ( . . . ) : T u p l e @ 1

6 5 , 9 3 2 1 7 4 8 ,50 7 1 8 0 8 0 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( . . . ) : T u p l e

7 4 , 6 2 8 0 2 8 6 ,63 5 7 6 7 1 6 8 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( . . . ) : T u p l e @ 0 @ 0

8 4 , 1 8 3 2 5 0 5 ,99 2 5 9 5 2 2 5 6 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( . . . ) : T u p l e @ 0 @ 0 @ 0

9 1 , 5 9 7 1 0 9 2 ,29 5 0 4 9 0 8 8 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( . . . ) : T u p l e @ 1

10 1 , 3 8 0 8 6 2 1 ,98 5 0 4 9 0 8 8 TT ! T r u t h T a b l e :: g e t T r e e () : T u p l e @ 0

11 0 , 7 3 2 1 1 4 1 ,05 6 5 3 0 5 5 s t a t i c E M F T V M ! E x e c E n v :: f i n d C e l l ( . . . ) : T u p l e

12 0 , 7 0 7 8 9 8 1 ,01 7 1 8 0 8 0 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( . . . ) : T u p l e @ 0

13 0 , 7 0 1 3 1 4 1 ,00 7 1 8 0 8 0 s t a t i c E M F T V M ! E x e c E n v :: g e t P a r t i t i o n ( . . . ) : T u p l e

14 0 , 0 1 0 9 3 6 0 ,02 2 8 1 5 TT ! C e l l :: g e t N o d e () : T u p l e

15 0 , 0 0 8 5 1 8 0 ,01 2 8 1 6 TT ! T r u t h T a b l e :: g e t T r e e () : T u p l e

16 0 , 0 0 5 4 9 9 0 ,01 255 r u l e C e l l 2 S u b t r e e @ a p p l i e r

17 0 , 0 0 4 5 6 8 0 ,01 2 5 6 0 r u l e C e l l 2 S u b t r e e @ m a t c h e r

18 0 , 0 0 3 4 2 1 0 ,00 2 5 6 0 r u l e C e l l 2 A s s i g n m e n t @ m a t c h e r

19 0 , 0 0 2 9 1 1 0 ,00 256 r u l e R o w 2 L e a f @ a p p l i e r

20 0 , 0 0 2 9 0 5 0 ,00 2 5 6 0 r u l e R o w 2 L e a f @ a p p l i e r @ 0

21 0 , 0 0 1 7 0 4 0 ,00 512 r u l e C e l l 2 A s s i g n m e n t @ a p p l i e r

22 0 , 0 0 0 1 3 1 0 ,00 1 r u l e T r u t h T a b l e 2 B D D @ a p p l i e r

23 0 , 0 0 0 0 1 5 0 ,00 8 r u l e I n p u t P o r t 2 I n p u t P o r t @ a p p l i e r

24 0 , 0 0 0 0 0 4 0 ,00 2 r u l e O u t p u t P o r t 2 O u t p u t P o r t @ a p p l i e r

25 0 , 0 0 0 0 0 1 0 ,00 1 s t a t i c E M F T V M ! E x e c E n v :: i n i t () : O b j e c t

26 0 , 0 0 0 0 0 0 0 ,00 1 s t a t i c E M F T V M ! E x e c E n v :: m a i n () : O b j e c t

27 T i m i n g d a t a :

28 L o a d i n g f i n i s h e d at 0 , 0 0 8 5 5 8 s e c o n d s ( d u r a t i o n : 0 , 0 0 8 5 5 8 s e c o n d s )

29 M a t c h i n g f i n i s h e d at 6 3 , 5 0 3 9 9 7 s e c o n d s ( d u r a t i o n : 6 3 , 4 9 5 4 3 9 s e c o n d s )

30 A p p l y i n g f i n i s h e d at 6 9 , 8 3 0 4 0 2 s e c o n d s ( d u r a t i o n : 6 , 3 2 6 4 0 5 s e c o n d s )

31 Post - a p p l y i n g f i n i s h e d at 6 9 , 8 3 0 5 1 7 s e c o n d s ( d u r a t i o n : 0 , 0 0 0 1 1 5 s e c o n d s )

32 R e c u r s i v e s t a g e f i n i s h e d at 6 9 , 8 3 0 5 2 9 s e c o n d s ( d u r a t i o n : 0 , 0 0 0 0 1 2 s e c o n d s )

33 E x e c u t i o n f i n i s h e d at 6 9 , 8 3 2 0 1 8 s e c o n d s ( d u r a t i o n : 0 , 0 0 1 5 0 1 s e c o n d s )

Listing 6: ATL/EMFTVM Profiler output 1

(7)

2 0 , 6 1 3 1 4 7 88 ,17 6 5 3 0 5 5 s t a t i c E M F T V M ! E x e c E n v :: f i n d C e l l ( c e l l : TT ! Cell , t r e e : T u p l e ) : T u p l e

3 0 , 0 1 0 0 2 4 1 ,44 1 4 8 4 8 s t a t i c E M F T V M ! E x e c E n v :: g e t P a r t i t i o n ( r o w s : S e q u e n c e , p o r t : TT ! P o r t ) : T u p l e @ 0 @ 0

4 0 , 0 0 9 4 2 8 1 ,36 255 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( r o w s : S e q u e n c e , u s a b l e P o r t s : S e q u e n c e ) : T u p l e

6 0 , 0 0 4 3 7 3 0 ,63 2 0 4 8 s t a t i c E M F T V M ! E x e c E n v :: g e t P a r t i t i o n ( r o w s : S e q u e n c e , p o r t : TT ! P o r t ) : T u p l e @ 1

9 0 , 0 0 3 7 4 8 0 ,54 2 8 1 5 TT ! C e l l :: g e t N o d e () : T u p l e

10 0 , 0 0 3 5 0 1 0 ,50 2 0 4 8 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( r o w s : S e q u e n c e , u s a b l e P o r t s : S e q u e n c e ) : T u p l e @ 0 @ 0

15 0 , 0 0 2 1 0 8 0 ,30 9 2 1 6 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( r o w s : S e q u e n c e , u s a b l e P o r t s : S e q u e n c e ) : T u p l e @ 0 @ 0 @ 0

16 0 , 0 0 1 6 8 9 0 ,24 255 s t a t i c E M F T V M ! E x e c E n v :: g e t P a r t i t i o n ( r o w s : S e q u e n c e , p o r t : TT ! P o r t ) : T u p l e

17 0 , 0 0 1 6 0 6 0 ,23 1 7 9 3 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( r o w s : S e q u e n c e , u s a b l e P o r t s : S e q u e n c e ) : T u p l e @ 1

19 0 , 0 0 1 3 8 3 0 ,20 255 s t a t i c E M F T V M ! E x e c E n v :: g e t T r e e ( r o w s : S e q u e n c e , u s a b l e P o r t s : S e q u e n c e ) : T u p l e @ 0

20 0 , 0 0 1 2 5 6 0 ,18 1 7 9 3 TT ! T r u t h T a b l e :: t r e e : T u p l e @ 0

22 0 , 0 0 0 0 2 8 0 ,00 1 TT ! T r u t h T a b l e :: t r e e : T u p l e

29 M a t c h i n g f i n i s h e d at 0 , 6 6 0 2 6 6 s e c o n d s ( d u r a t i o n : 0 , 6 5 2 7 0 3 s e c o n d s )

30 A p p l y i n g f i n i s h e d at 0 , 7 0 2 9 6 7 s e c o n d s ( d u r a t i o n : 0 , 0 4 2 7 0 0 s e c o n d s )

31 Post - a p p l y i n g f i n i s h e d at 0 , 7 0 3 0 1 0 s e c o n d s ( d u r a t i o n : 0 , 0 0 0 0 4 3 s e c o n d s )

32 R e c u r s i v e s t a g e f i n i s h e d at 0 , 7 0 3 0 2 1 s e c o n d s ( d u r a t i o n : 0 , 0 0 0 0 1 1 s e c o n d s )

33 E x e c u t i o n f i n i s h e d at 0 , 7 0 3 7 5 5 s e c o n d s ( d u r a t i o n : 0 , 0 0 0 7 4 5 s e c o n d s )

Listing 7: ATL/EMFTVM Profiler output 2

2 0 , 5 8 0 8 7 6 87 ,77 6 2 0 4 1 5 s t a t i c E M F T V M ! E x e c E n v :: f i n d C e l l ( c e l l : TT ! Cell , t r e e : T u p l e ) : T u p l e

9 0 , 0 0 3 3 0 6 0 ,50 2 5 6 0 TT ! C e l l :: n o d e : T u p l e

Listing 8: ATL/EMFTVM Profiler output 3

(8)

14 0 , 0 0 1 8 8 7 2 ,41 255 s t a t i c E M F T V M ! E x e c E n v :: c o l l e c t A l l N o d e s ( t r e e : T u p l e ) : S e q u e n c e

21 0 , 0 0 0 4 4 4 0 ,57 1 TT ! T r u t h T a b l e :: n o d e s B y C e l l : Map

22 0 , 0 0 0 1 0 3 0 ,13 255 TT ! T r u t h T a b l e :: n o d e s B y C e l l : M a p @ 0

Listing 9: ATL/EMFTVM Profiler output 4

6 0 , 0 0 2 7 5 4 4 ,15 256 TT ! Row :: t r u e C e l l s B y P o r t : Map

13 0 , 0 0 2 0 0 1 3 ,01 255 s t a t i c E M F T V M ! E x e c E n v :: c o l l e c t A l l N o d e s ( t r e e : T u p l e ) : S e q u e n c e

14 0 , 0 0 1 9 7 3 2 ,97 256 TT ! Row :: f a l s e C e l l s B y P o r t : Map

20 0 , 0 0 1 2 1 2 1 ,82 2 5 6 0 TT ! Row :: t r u e C e l l s B y P o r t : M a p @ 0

22 0 , 0 0 1 1 2 0 1 ,69 2 5 6 0 TT ! Row :: f a l s e C e l l s B y P o r t : M a p @ 0

23 0 , 0 0 0 5 7 2 0 ,86 1 2 8 5 TT ! Row :: t r u e C e l l s B y P o r t : M a p @ 1

24 0 , 0 0 0 5 0 2 0 ,76 1 2 7 5 TT ! Row :: f a l s e C e l l s B y P o r t : M a p @ 1

25 0 , 0 0 0 4 2 2 0 ,63 1 TT ! T r u t h T a b l e :: n o d e s B y C e l l : Map

26 0 , 0 0 0 0 9 8 0 ,15 255 TT ! T r u t h T a b l e :: n o d e s B y C e l l : M a p @ 0