Home » Modeling » EMF » ChangeDescription applyAndReverse performance issue
|
| Re: ChangeDescription applyAndReverse performance issue [message #423094 is a reply to message #423091] |
Tue, 23 September 2008 00:34   |
Eclipse User |
|
|
|
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 |
 Bryan Hunt
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 |
| Eclipse User |
|
|
|
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 |
Ed Merks
Messages: 33140
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
>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: ChangeDescription applyAndReverse performance issue [message #423120 is a reply to message #423111] |
Tue, 23 September 2008 14:39 |
Bryan Hunt
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 |
Bryan Hunt
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
|
|
|
Goto Forum:
Current Time: Thu Apr 25 10:36:38 GMT 2024
Powered by FUDForum. Page generated in 0.03000 seconds |
] 
Search
Help
Register
Login
Home
