Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » ChangeDescription applyAndReverse performance issue
ChangeDescription applyAndReverse performance issue [message #423091] Mon, 22 September 2008 21:46 Go to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
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
Re: ChangeDescription applyAndReverse performance issue [message #423094 is a reply to message #423091] Tue, 23 September 2008 00:34 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

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
>
Re: ChangeDescription applyAndReverse performance issue [message #423095 is a reply to message #423094] Tue, 23 September 2008 06:16 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
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@zeligsoft.com> 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
Re: ChangeDescription applyAndReverse performance issue [message #423104 is a reply to message #423095] Tue, 23 September 2008 13:18 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

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@zeligsoft.com> 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
>
>
Re: ChangeDescription applyAndReverse performance issue [message #423111 is a reply to message #423104] Tue, 23 September 2008 13:54 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30804
Registered: July 2009
Senior Member
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@zeligsoft.com> 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
>>
>>
Re: ChangeDescription applyAndReverse performance issue [message #423120 is a reply to message #423111] Tue, 23 September 2008 14:39 Go to previous messageGo to next message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
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@gmail.com> 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@zeligsoft.com> 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
Re: ChangeDescription applyAndReverse performance issue [message #423132 is a reply to message #423120] Tue, 23 September 2008 16:09 Go to previous message
Bryan Hunt is currently offline Bryan HuntFriend
Messages: 366
Registered: July 2009
Senior Member
I just finished writing my own change recorder. It's a big hack, but
it can keep up with my transaction rate.

On 2008-09-23 09:39:51 -0500, Bryan Hunt <bhunt@mac.com> 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@gmail.com> 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@zeligsoft.com> 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
Previous Topic:[CDO] CDOResource.isLoaded()
Next Topic:Re: JMerge customization
Goto Forum:
  


Current Time: Mon Jan 20 07:07:48 GMT 2020

Powered by FUDForum. Page generated in 0.02188 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top