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

[Tero Parviainen <tero.parviainen@xxxxxxxxxx>]

Hi Stefan,

There indeed is a noticeable performance penalty, but I'm still optimistic something can be done about that.
I'm sorry to say I'm a bit tied up at the moment and aren't able to join the call, but I'll elaborate on the mailing list later, and hope to speak to you next week.

Br,
Tero

________________________________________
From: Stefan Edlund [edlund@xxxxxxxxxxxxxxx]
Sent: 05 October 2010 23:48
To: Tero Parviainen
Cc: stem-dev@xxxxxxxxxxx
Subject: Re: [stem-dev] Effects of enabling CDO for STEM

Hi Tero,

this is a great test, thank you very much for trying this out! If I understood your tests correctly, there seems to be a pretty severe performance penalty enabling CDO even just running standalone?

I added an item for tomorrow on the STEM agenda if you can make it. Perhaps you can reiterate and clarify what you discovered so far.

Regards,
/ Stefan


Stefan Edlund
Public Health and Computer Science Research
IBM Almaden Research Center
(408) 927-1766 edlund@xxxxxxxxxxxxxxx
"Bad news is good news. Good news is no news. No news is bad news."

[cid:1__=07BBFD20DFE277A68f9e8a93df938@xxxxxxxxxx]Tero Parviainen ---10/03/2010 08:29:32 AM---> I'm not seeing any noticeable performance degradation after the CDO refactoring, but I haven't > a


From:
Tero Parviainen <tero.parviainen@xxxxxxxxxx>

To:
STEM developer mailing list <stem-dev@xxxxxxxxxxx>

Date:
10/03/2010 08:29 AM

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

Sent by:
stem-dev-bounces@xxxxxxxxxxx

________________________________



> 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
_______________________________________________
stem-dev mailing list
stem-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stem-dev