Tuning ELists

Just solved a serious performance problem. I programmtically constructed a rather big EMF model. It took ages so I started a profiler: Most of the time was spend in the BasicEList.contains(EObject) method. 

This is due to the fact that the corresponding EReferences have the unique flag set to true. EMF makes sure each element appears only once in the list of that reference. This is good, but performs poor for big growing lists.

As I construct the model from scratch I can make sure there will be no duplicates. So instead of

parent.getFeature().add(child);

I cast to BasicEList and call

((BasicEList<EObject>) parent.getFeature()).addUnique(child);

In my case, that reduced the execution time to a fifth !

Testing Trees

Working on parsers a lot recently, I have to write quite a bunch of tedious unit tests. Each of these tests analyses an EMF AST model which is the output of the parser. It checks if all nodes are at the right location and if all properties are set correctly. The tests look awful and debugging is a nightmare.

Using Xtext, it is quite easy to create a DSL for tree comparison. I can now describe expected tree results as

Extension {
name=Identifier(value='foo')
params=[
DeclaredParameter {
name=Identifier(value='this')
type=Identifier(value='Object')
},
DeclaredParameter {
name=Identifier(value='that')
type=Identifier(value='Object')
}]
}

where Extension, Identifier and DeclaredParameter are EClasses, name,params and type are EReferences and value is a attribute.

Writing such a DSL and an interpreter doesn't take you a day and will save you a lot of time and mental sanity in the future.

Converging Model Editors

Yesterday, Sven implemented an EMF Resource that serializes its content in Xtext format. We combined it with a graphical editor and the new EValidator adapter for oAW check. Generating everything, we finally got three synchronized editors all showing different representations of the same resource: Graphical, in Xtext and in an Ecore tree. Even complex changes in one editor were automatically transferred to all other editors on save and two of the editors even used the same checks for validation. 

That really rocked.

And it shows how great EMF and oAW really are. In the future, it should be easy to write DSLs with mixed representations, e.g. a graphical part for the element connections and a textual part for the details.

I am really looking forward to work on a closer integration of  oAW and EMF. There's so much potential. 

Advanced GMF

Having collected about two years of experience with Eclipse's Graphical Modeling Framework, I am now trying to summarize what could be improved or added to the framework. These are my favorites

1. Support for a singleton editing domain (keep all semantic and diagram resources in the same resource set)
   
2. Support for non-canonical diagrams (multiple diagrams for the same semantic model)
   
3. Enable the OpenDiagramEditPolicy (linked diagrams)

Most of these issues can be implemented without touching GMF runtime code, i.e. by means of aspectual template changes and extensions. But as these are really fundamental and reoccurring topics, I'd rather see them as base functionality inside the original framework. Maybe I can push the GMF project in that direction?

Here it is...

Finally, web 2.0 has reached me. So here is my new blog.