| [news.eclipse.tools.emf] Re: ChangeDescription applyAndReverse performance issue |
On 2008-09-23 09:39:51 -0500, Bryan Hunt <bhunt@xxxxxxx> said:
I do not have any adapters attached to my model. If I had the time, I'd try to profile applyAndReverse(), but I'm under a deadline that's quickly approaching and I need this code working yesterday.
Bryan
On 2008-09-23 08:54:45 -0500, Ed Merks <Ed.Merks@xxxxxxxxx> said:
Guys,
It's effectively impossible to comment about performance problems without something more specific to go on. Of course one should expect that processing time will be proportional to the size of the delta.
In the end, all performance tuning must rely on careful measurements to find the bottlenecks and then fix those. I could imagine that something like applyAndReverse might well be expensive simply because of listeners responding to notifications and that this cost would go unnoticed if one was just testing this in isolation while nothing else was observing the instance. Does your model have listeners/adapters that will see the effects of the apply?
Christian W. Damus wrote:Hi, Bryan,
I see. Since your current algorithm does an apply-and-reverse to restore the previous state and then another one to restore it, you may be able to roll your own EContentAdapter (modified like a ChangeRecorder to not detach itself from removed objects) that builds a forward delta as it receives Notifications, rather than a backward delta as the ChangeRecorder does. I suppose that a similar structure of FeatureChanges to what the ChangeRecorder uses could be employed in building a forward delta.
I wonder whether the EMFT Compare component has any delta algorithms that you can borrow, that work with a stream of Notifications?
Cheers,
Christian
Bryan Hunt wrote: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