Re: [stem-dev] Effects of enabling CDO for STEM

[Tero Parviainen <tero.parviainen@xxxxxxxxxx>]

> I'm not seeing any noticeable performance degradation after the CDO refactoring, but I haven't
> actually measured this.

I got around to doing some performance tests on both CPU and memory usage, and wrote about the results here: http://github.com/teropa/stem/wiki/Effects-of-CDO-on-STEM-Performance

> Here are some of my main observations

I noticed one additional caveat in converting the code to CDO: All default values need to be set in the "Default value literal" property of the EMF model and generated from that, because otherwise EMF does not know about them and they won't get used. Of course, they can alternatively be set manually during object construction. There were a few cases where default values were annotated "@generated NOT" (e.g. SequentialSequencerImpl.TIME_INCREMENT_EDEFAULT), and I changed those in my cdo branch.

Br,
Tero

________________________________________
From: stem-dev-bounces@xxxxxxxxxxx [stem-dev-bounces@xxxxxxxxxxx] On Behalf Of Tero Parviainen [tero.parviainen@xxxxxxxxxx]
Sent: 29 September 2010 17:48
To: STEM developer mailing list
Subject: [stem-dev] Effects of enabling CDO for STEM

Hi,

I've been exploring the practical consequences of CDO-enabling the STEM EMF model. I did the genmodel conversion by following the instructions in the CDO wiki (http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO), and the code is in my Github repo at http://github.com/teropa/stem/tree/cdo.

Here are some of my main observations:

- CDO requires we use either dynamic or reflective feature delegation in EMF models. The main
  effect this has to the current application code is that direct field access cannot be used in EMF
  models. Thus, all places where fields are accessed directly in non-generated code have to be
  changed to getter/setter access (this.canonicalGraph -> getCanonicalGraph()). This requires
  quite a large amount of changes in the code, but they are for the most part simple to make.

- EMF seems to prefer identity semantics for implementing equals/hashCode, and CDO actually
  enforces this by making them final in CDOObjectImpl. There are a few cases in the STEM code
  where equals/hashCode have been overriden to use value semantics (most notably STEMTime),
  and this doesn't work with CDO. Places where these objects are tested for equality or used in
  HashMaps/HashSets would have to be changed.

- I'm not seeing any noticeable performance degradation after the CDO refactoring, but I haven't
  actually measured this. I also haven't yet used any of the distribution capabilities of CDO, so
  I cannot yet comment on how well that works.

Br,
Tero

_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev