[news.eclipse.tools.emf] Re: ChangeDescription applyAndReverse performan

[Bryan Hunt <bhunt@xxxxxxx>]

The performace problem is the amount of time required by 
applyAndReverse().  My application has a real-time aspect to it, and 
calling applyAndReverse() is holding up one of our threads to the point 
that it can't keep up with the work it needs to do in a given time 
span.  Before I changed this part of the code to use EMF and the 
ChangeRecorder, I had my own algorithm for finding the delta.  It 
wasn't as generic as the ChangeRecorder, but it could keep up with the 
transaction rate.  I don't really want to write my own ChangeRecorder, 
but I don't see another way to get that part of the code to run faster. 
I'm not looking for a "fix" to the ChangeRecorder, but more for any 
suggestions at an alternative.  I may try processing the delta at a 
time interval instead of on demand, but I'm concerned that the time 
required to do an applyAndReverse() scales with the size of the delta.

On 2008-09-22 19:34:34 -0500, "Christian W. Damus" <cdamus@xxxxxxxxxxxxx> said:

> Hi, Bryan,
>
> What do you see as a performance problem?  The ChangeRecorder has a lot 
> of work to do in applying itself and in reversing itself.  Presumably, 
> your application won't work if it doesn't have these changes to analyze.
>
> I think you'll have to be more specific about what you think is the 
> performance problem in order to get a useful response.  For what it's 
> trying to do, which is to provide a general-purpose EMF-serializable 
> model of changes, the ChangeDescription is pretty efficient.
>
> Cheers,
>
> Christian
>
> Bryan Hunt wrote:
> > I've got a performance problem that I've narrowed down to 
> > applyAndReverse() on a ChangeDescription.  My code looks something like:
> >
> > ChangeDescription changes = changeRecorder.endRecording();
> > changes.applyAndReverse();
> >
> > // process changes
> >
> > change.applyAndReverse();
> > changeRecorder.beginRecording(Collections.singleton(this));
> >
> > I first commented out my processing code and that made no difference in 
> > the performance.  As soon as I commented out both calls to 
> > applyAndReverse(), my performance problem was gone.  I think my 
> > solution will be to write a custom change recorder that that captures 
> > the new state instead of the old state.  It won't support rollbacks, 
> > but I hope it will be much faster.  Comments?
> >
> > Bryan