Home » Modeling » EMF » Workbench event loop stuck after EMF bulk update
| Workbench event loop stuck after EMF bulk update [message #417723] |
Tue, 25 March 2008 07:10  |
 Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
[Cross-posted because unclear whether problem is with EMF or platform]
My app uses bulk updates to set attribute values on large sets of
EObjects (e.g. 5,000 items). These sets are displayed in a treeview;
model, view and commands are wired together with EMF.Edit.
Here's my problem: after error-free completion of a bulk update command
(on a tx command stack), and after all EMF model notifications have
already been processed, the callstack unwinds back to the workbench's
event loop and there appears to find an enormous amount of events on the
queue. App then proceeds to eat up 100% CPU and GUI becomes non-responsive.
Reason I say "appears" to find, is because OS.g_main_context_iteration()
keeps returning true, but Display.eventQueue is in fact null, so the
endless calls to runDeferredEvents do nothing.
Anyone has any idea what is amiss here?
Thanks very much,
Jasper.
PS. Eclipse 3.3.2, EMF 2.3.2, GTK.
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417729 is a reply to message #417723] |
Tue, 25 March 2008 12:26  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Jasper,
Gosh, this seems like perhaps a transaction question that requires
Christian's attention. Perhaps there's some issue with a lock that's
not been released... This problem only happens if you do thousands of
objects not just when you do a dozen say?
Jasper wrote:
> [Cross-posted because unclear whether problem is with EMF or platform]
>
> My app uses bulk updates to set attribute values on large sets of
> EObjects (e.g. 5,000 items). These sets are displayed in a treeview;
> model, view and commands are wired together with EMF.Edit.
>
> Here's my problem: after error-free completion of a bulk update
> command (on a tx command stack), and after all EMF model notifications
> have already been processed, the callstack unwinds back to the
> workbench's event loop and there appears to find an enormous amount of
> events on the queue. App then proceeds to eat up 100% CPU and GUI
> becomes non-responsive.
>
> Reason I say "appears" to find, is because
> OS.g_main_context_iteration() keeps returning true, but
> Display.eventQueue is in fact null, so the endless calls to
> runDeferredEvents do nothing.
>
> Anyone has any idea what is amiss here?
>
> Thanks very much,
> Jasper.
>
> PS. Eclipse 3.3.2, EMF 2.3.2, GTK.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417733 is a reply to message #417729] |
Tue, 25 March 2008 13:56 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Ed, Jasper,
I don't know of anything in the EMF Transaction infrastructure that can mess
up the event-processing loop in the SWT Display. There isn't any direct
interaction with the UI subsystem.
Does this happen in a similar bulk update with a non-transactional command
stack? i.e., try it in a ChangeCommand on a basic stack
Cheers,
Christian
Ed Merks wrote:
> Jasper,
>
> Gosh, this seems like perhaps a transaction question that requires
> Christian's attention. Perhaps there's some issue with a lock that's
> not been released... This problem only happens if you do thousands of
> objects not just when you do a dozen say?
>
>
> Jasper wrote:
>> [Cross-posted because unclear whether problem is with EMF or platform]
>>
>> My app uses bulk updates to set attribute values on large sets of
>> EObjects (e.g. 5,000 items). These sets are displayed in a treeview;
>> model, view and commands are wired together with EMF.Edit.
>>
>> Here's my problem: after error-free completion of a bulk update
>> command (on a tx command stack), and after all EMF model notifications
>> have already been processed, the callstack unwinds back to the
>> workbench's event loop and there appears to find an enormous amount of
>> events on the queue. App then proceeds to eat up 100% CPU and GUI
>> becomes non-responsive.
>>
>> Reason I say "appears" to find, is because
>> OS.g_main_context_iteration() keeps returning true, but
>> Display.eventQueue is in fact null, so the endless calls to
>> runDeferredEvents do nothing.
>>
>> Anyone has any idea what is amiss here?
>>
>> Thanks very much,
>> Jasper.
>>
>> PS. Eclipse 3.3.2, EMF 2.3.2, GTK.
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417738 is a reply to message #417729] |
Tue, 25 March 2008 16:46 |
Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
Ed,
The deterioration depends on size: doing 5,000 updates leaves the GUI
paralyzed; doing 1,000 leaves it extremely sluggish but still responding,
doing a few hundred leaves it usable but not as responsive as it should
be. Of course this suggests that the problem is always there, but that for
small updates it's just not noticeable.
I've also noticed that while on GTK the GUI becomes sluggish, on Win the
same test case leaves the tree view flickering for minutes as if it's
constantly refreshing. Looks like the same or a related problem, but
haven't been able to debug on Win as my dev machine is GTK.
Would like to know why OS.g_main_context_iteration() returns true forever,
but I don't have the GTK knowledge to debug low-level code. By means of a
test, I'll swap the tx editing domain for a regular one tomorrow and see
if that changes things. Will update.
Thanks,
Jasper.
Ed Merks wrote:
> Jasper,
> Gosh, this seems like perhaps a transaction question that requires
> Christian's attention. Perhaps there's some issue with a lock that's
> not been released... This problem only happens if you do thousands of
> objects not just when you do a dozen say?
> Jasper wrote:
>> [Cross-posted because unclear whether problem is with EMF or platform]
>>
>> My app uses bulk updates to set attribute values on large sets of
>> EObjects (e.g. 5,000 items). These sets are displayed in a treeview;
>> model, view and commands are wired together with EMF.Edit.
>>
>> Here's my problem: after error-free completion of a bulk update
>> command (on a tx command stack), and after all EMF model notifications
>> have already been processed, the callstack unwinds back to the
>> workbench's event loop and there appears to find an enormous amount of
>> events on the queue. App then proceeds to eat up 100% CPU and GUI
>> becomes non-responsive.
>>
>> Reason I say "appears" to find, is because
>> OS.g_main_context_iteration() keeps returning true, but
>> Display.eventQueue is in fact null, so the endless calls to
>> runDeferredEvents do nothing.
>>
>> Anyone has any idea what is amiss here?
>>
>> Thanks very much,
>> Jasper.
>>
>> PS. Eclipse 3.3.2, EMF 2.3.2, GTK.
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417740 is a reply to message #417738] |
Tue, 25 March 2008 18:20 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Jasper,
Is something posting a huge number of events to the queue and perhaps
overflowing it?
Jasper wrote:
> Ed,
>
> The deterioration depends on size: doing 5,000 updates leaves the GUI
> paralyzed; doing 1,000 leaves it extremely sluggish but still
> responding, doing a few hundred leaves it usable but not as
> responsive as it should be. Of course this suggests that the problem
> is always there, but that for small updates it's just not noticeable.
>
> I've also noticed that while on GTK the GUI becomes sluggish, on Win
> the same test case leaves the tree view flickering for minutes as if
> it's constantly refreshing. Looks like the same or a related problem,
> but haven't been able to debug on Win as my dev machine is GTK.
>
> Would like to know why OS.g_main_context_iteration() returns true
> forever, but I don't have the GTK knowledge to debug low-level code.
> By means of a test, I'll swap the tx editing domain for a regular one
> tomorrow and see if that changes things. Will update.
>
> Thanks,
> Jasper.
>
>
> Ed Merks wrote:
>
>> Jasper,
>
>> Gosh, this seems like perhaps a transaction question that requires
>> Christian's attention. Perhaps there's some issue with a lock that's
>> not been released... This problem only happens if you do thousands
>> of objects not just when you do a dozen say?
>
>
>> Jasper wrote:
>>> [Cross-posted because unclear whether problem is with EMF or platform]
>>>
>>> My app uses bulk updates to set attribute values on large sets of
>>> EObjects (e.g. 5,000 items). These sets are displayed in a treeview;
>>> model, view and commands are wired together with EMF.Edit.
>>>
>>> Here's my problem: after error-free completion of a bulk update
>>> command (on a tx command stack), and after all EMF model
>>> notifications have already been processed, the callstack unwinds
>>> back to the workbench's event loop and there appears to find an
>>> enormous amount of events on the queue. App then proceeds to eat up
>>> 100% CPU and GUI becomes non-responsive.
>>>
>>> Reason I say "appears" to find, is because
>>> OS.g_main_context_iteration() keeps returning true, but
>>> Display.eventQueue is in fact null, so the endless calls to
>>> runDeferredEvents do nothing.
>>>
>>> Anyone has any idea what is amiss here?
>>>
>>> Thanks very much,
>>> Jasper.
>>>
>>> PS. Eclipse 3.3.2, EMF 2.3.2, GTK.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417892 is a reply to message #417740] |
Fri, 28 March 2008 05:36 |
Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
Ed,
Yep, I found the problem in our own code. We had a redundant adapter
listening for model changes and issuing an asyncExec call to refresh the
tree view once for every update. After the command completed, on Windows
the event loop would actually execute these updates, whereas on GTK
their volume seems to corrupt the event queue somehow.
Either way, clunky code on our part was at fault.
Thanks for your help,
Jasper.
Ed Merks wrote:
> Jasper,
>
> Is something posting a huge number of events to the queue and perhaps
> overflowing it?
>
>
> Jasper wrote:
>> Ed,
>>
>> The deterioration depends on size: doing 5,000 updates leaves the GUI
>> paralyzed; doing 1,000 leaves it extremely sluggish but still
>> responding, doing a few hundred leaves it usable but not as
>> responsive as it should be. Of course this suggests that the problem
>> is always there, but that for small updates it's just not noticeable.
>>
>> I've also noticed that while on GTK the GUI becomes sluggish, on Win
>> the same test case leaves the tree view flickering for minutes as if
>> it's constantly refreshing. Looks like the same or a related problem,
>> but haven't been able to debug on Win as my dev machine is GTK.
>>
>> Would like to know why OS.g_main_context_iteration() returns true
>> forever, but I don't have the GTK knowledge to debug low-level code.
>> By means of a test, I'll swap the tx editing domain for a regular one
>> tomorrow and see if that changes things. Will update.
>>
>> Thanks,
>> Jasper.
>>
>>
>> Ed Merks wrote:
>>
>>> Jasper,
>>
>>> Gosh, this seems like perhaps a transaction question that requires
>>> Christian's attention. Perhaps there's some issue with a lock that's
>>> not been released... This problem only happens if you do thousands
>>> of objects not just when you do a dozen say?
>>
>>
>>> Jasper wrote:
>>>> [Cross-posted because unclear whether problem is with EMF or platform]
>>>>
>>>> My app uses bulk updates to set attribute values on large sets of
>>>> EObjects (e.g. 5,000 items). These sets are displayed in a treeview;
>>>> model, view and commands are wired together with EMF.Edit.
>>>>
>>>> Here's my problem: after error-free completion of a bulk update
>>>> command (on a tx command stack), and after all EMF model
>>>> notifications have already been processed, the callstack unwinds
>>>> back to the workbench's event loop and there appears to find an
>>>> enormous amount of events on the queue. App then proceeds to eat up
>>>> 100% CPU and GUI becomes non-responsive.
>>>>
>>>> Reason I say "appears" to find, is because
>>>> OS.g_main_context_iteration() keeps returning true, but
>>>> Display.eventQueue is in fact null, so the endless calls to
>>>> runDeferredEvents do nothing.
>>>>
>>>> Anyone has any idea what is amiss here?
>>>>
>>>> Thanks very much,
>>>> Jasper.
>>>>
>>>> PS. Eclipse 3.3.2, EMF 2.3.2, GTK.
>>
>>
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417894 is a reply to message #417892] |
Fri, 28 March 2008 07:36 |
Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
Oops, previous post was premature. Removing our clunky code fixed some
problems: the phantom events on GTK and the flickering on Windows.
However, the GUI still becomes unresponsive on both Win and GTK if the
updated elements are all at the same level in the tree.
I've noticed that AdapterFactory.notifyChanged(*) collects all its
notifications in an instance of ViewerRefresh, that is later
asyncExec'ed. When executed, ViewerRefresh calls
StructuredViewer.update() once for every collected notification. It is
the execution of these updates that now causes the bulk of the slowdown.
Perhaps I shouldn't expect a treeview to respond well when several
thousand of its elements are updated? I find it odd though that
updating the tree takes so many CPU cycles, since only visible items
must immediately be re-rendered, and there are at most 40 or so of those.
Regards,
Jasper.
Jasper wrote:
> Ed,
>
> Yep, I found the problem in our own code. We had a redundant adapter
> listening for model changes and issuing an asyncExec call to refresh the
> tree view once for every update. After the command completed, on Windows
> the event loop would actually execute these updates, whereas on GTK
> their volume seems to corrupt the event queue somehow.
>
> Either way, clunky code on our part was at fault.
>
> Thanks for your help,
> Jasper.
>
>
> Ed Merks wrote:
>> Jasper,
>>
>> Is something posting a huge number of events to the queue and perhaps
>> overflowing it?
>>
>>
>> Jasper wrote:
>>> Ed,
>>>
>>> The deterioration depends on size: doing 5,000 updates leaves the GUI
>>> paralyzed; doing 1,000 leaves it extremely sluggish but still
>>> responding, doing a few hundred leaves it usable but not as
>>> responsive as it should be. Of course this suggests that the problem
>>> is always there, but that for small updates it's just not noticeable.
>>>
>>> I've also noticed that while on GTK the GUI becomes sluggish, on Win
>>> the same test case leaves the tree view flickering for minutes as if
>>> it's constantly refreshing. Looks like the same or a related problem,
>>> but haven't been able to debug on Win as my dev machine is GTK.
>>>
>>> Would like to know why OS.g_main_context_iteration() returns true
>>> forever, but I don't have the GTK knowledge to debug low-level code.
>>> By means of a test, I'll swap the tx editing domain for a regular one
>>> tomorrow and see if that changes things. Will update.
>>>
>>> Thanks,
>>> Jasper.
>>>
>>>
>>> Ed Merks wrote:
>>>
>>>> Jasper,
>>>
>>>> Gosh, this seems like perhaps a transaction question that requires
>>>> Christian's attention. Perhaps there's some issue with a lock
>>>> that's not been released... This problem only happens if you do
>>>> thousands of objects not just when you do a dozen say?
>>>
>>>
>>>> Jasper wrote:
>>>>> [Cross-posted because unclear whether problem is with EMF or platform]
>>>>>
>>>>> My app uses bulk updates to set attribute values on large sets of
>>>>> EObjects (e.g. 5,000 items). These sets are displayed in a
>>>>> treeview; model, view and commands are wired together with EMF.Edit.
>>>>>
>>>>> Here's my problem: after error-free completion of a bulk update
>>>>> command (on a tx command stack), and after all EMF model
>>>>> notifications have already been processed, the callstack unwinds
>>>>> back to the workbench's event loop and there appears to find an
>>>>> enormous amount of events on the queue. App then proceeds to eat up
>>>>> 100% CPU and GUI becomes non-responsive.
>>>>>
>>>>> Reason I say "appears" to find, is because
>>>>> OS.g_main_context_iteration() keeps returning true, but
>>>>> Display.eventQueue is in fact null, so the endless calls to
>>>>> runDeferredEvents do nothing.
>>>>>
>>>>> Anyone has any idea what is amiss here?
>>>>>
>>>>> Thanks very much,
>>>>> Jasper.
>>>>>
>>>>> PS. Eclipse 3.3.2, EMF 2.3.2, GTK.
>>>
>>>
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417903 is a reply to message #417894] |
Fri, 28 March 2008 12:11 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020708050300020103040208
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Jasper,
The way that code is written, it should fold notifications whose
processing is still pending so I don't imagine this should flood the queue.
public void notifyChanged(Notification notification)
{
if (viewer != null && viewer.getControl() != null &&
!viewer.getControl().isDisposed())
{
// If the notification is an IViewerNotification, it specifies
how ViewerRefresh should behave. Otherwise fall
// back to NotifyChangedToViewerRefresh, which determines how
to refresh the viewer directly from the model
// notification.
//
if (notification instanceof IViewerNotification)
{
if (viewerRefresh == null)
{
viewerRefresh = new ViewerRefresh(viewer);
}
* if
(viewerRefresh.addNotification((IViewerNotification)notifica tion))*
{
viewer.getControl().getDisplay().asyncExec(viewerRefresh);
}
}
else
{
NotifyChangedToViewerRefresh.handleNotifyChanged(
viewer,
notification.getNotifier(),
notification.getEventType(),
notification.getFeature(),
notification.getOldValue(),
notification.getNewValue(),
notification.getPosition());
}
}
}
However, I imagine that doing 1000 individual refreshes might be far
less efficient than just invoking a full refresh for the whole tree.
public void run()
{
if (viewer != null && viewer.getControl() != null &&
!viewer.getControl().isDisposed())
{
List<IViewerNotification> current;
synchronized (this)
{
current = notifications;
notifications = null;
}
if (current != null)
{
* for (IViewerNotification viewerNotification : current)*
{
refresh(viewerNotification);
}
}
}
}
Jasper wrote:
> Oops, previous post was premature. Removing our clunky code fixed some
> problems: the phantom events on GTK and the flickering on Windows.
> However, the GUI still becomes unresponsive on both Win and GTK if the
> updated elements are all at the same level in the tree.
>
> I've noticed that AdapterFactory.notifyChanged(*) collects all its
> notifications in an instance of ViewerRefresh, that is later
> asyncExec'ed. When executed, ViewerRefresh calls
> StructuredViewer.update() once for every collected notification. It is
> the execution of these updates that now causes the bulk of the slowdown.
>
> Perhaps I shouldn't expect a treeview to respond well when several
> thousand of its elements are updated? I find it odd though that
> updating the tree takes so many CPU cycles, since only visible items
> must immediately be re-rendered, and there are at most 40 or so of those.
>
> Regards,
> Jasper.
>
>
> Jasper wrote:
>> Ed,
>>
>> Yep, I found the problem in our own code. We had a redundant adapter
>> listening for model changes and issuing an asyncExec call to refresh
>> the tree view once for every update. After the command completed, on
>> Windows the event loop would actually execute these updates, whereas
>> on GTK their volume seems to corrupt the event queue somehow.
>>
>> Either way, clunky code on our part was at fault.
>>
>> Thanks for your help,
>> Jasper.
>>
>>
>> Ed Merks wrote:
>>> Jasper,
>>>
>>> Is something posting a huge number of events to the queue and
>>> perhaps overflowing it?
>>>
>>>
>>> Jasper wrote:
>>>> Ed,
>>>>
>>>> The deterioration depends on size: doing 5,000 updates leaves the
>>>> GUI paralyzed; doing 1,000 leaves it extremely sluggish but still
>>>> responding, doing a few hundred leaves it usable but not as
>>>> responsive as it should be. Of course this suggests that the
>>>> problem is always there, but that for small updates it's just not
>>>> noticeable.
>>>>
>>>> I've also noticed that while on GTK the GUI becomes sluggish, on
>>>> Win the same test case leaves the tree view flickering for minutes
>>>> as if it's constantly refreshing. Looks like the same or a related
>>>> problem, but haven't been able to debug on Win as my dev machine is
>>>> GTK.
>>>>
>>>> Would like to know why OS.g_main_context_iteration() returns true
>>>> forever, but I don't have the GTK knowledge to debug low-level
>>>> code. By means of a test, I'll swap the tx editing domain for a
>>>> regular one tomorrow and see if that changes things. Will update.
>>>>
>>>> Thanks,
>>>> Jasper.
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> Jasper,
>>>>
>>>>> Gosh, this seems like perhaps a transaction question that requires
>>>>> Christian's attention. Perhaps there's some issue with a lock
>>>>> that's not been released... This problem only happens if you do
>>>>> thousands of objects not just when you do a dozen say?
>>>>
>>>>
>>>>> Jasper wrote:
>>>>>> [Cross-posted because unclear whether problem is with EMF or
>>>>>> platform]
>>>>>>
>>>>>> My app uses bulk updates to set attribute values on large sets of
>>>>>> EObjects (e.g. 5,000 items). These sets are displayed in a
>>>>>> treeview; model, view and commands are wired together with EMF.Edit.
>>>>>>
>>>>>> Here's my problem: after error-free completion of a bulk update
>>>>>> command (on a tx command stack), and after all EMF model
>>>>>> notifications have already been processed, the callstack unwinds
>>>>>> back to the workbench's event loop and there appears to find an
>>>>>> enormous amount of events on the queue. App then proceeds to eat
>>>>>> up 100% CPU and GUI becomes non-responsive.
>>>>>>
>>>>>> Reason I say "appears" to find, is because
>>>>>> OS.g_main_context_iteration() keeps returning true, but
>>>>>> Display.eventQueue is in fact null, so the endless calls to
>>>>>> runDeferredEvents do nothing.
>>>>>>
>>>>>> Anyone has any idea what is amiss here?
>>>>>>
>>>>>> Thanks very much,
>>>>>> Jasper.
>>>>>>
>>>>>> PS. Eclipse 3.3.2, EMF 2.3.2, GTK.
>>>>
>>>>
--------------020708050300020103040208
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jasper,<br>
<br>
The way that code is written, it should fold notifications whose
processing is still pending so I don't imagine this should flood the
queue.<br>
<blockquote><small>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417940 is a reply to message #417903] |
Mon, 31 March 2008 08:34 |
Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
Ed,
Yes, it is that for-loop that you boldfaced in the second code snippet,
that is very slow when the number of notifications is large.
As for the folding logic, I didn't really analyze the implementation of
ViewerRefresh#merge in detail, but shouldn't this logic be able to
choose one full refresh over several 1,000 calls to
structuredViewer.update(*)?
Thanks,
Jasper.
Ed Merks wrote:
> Jasper,
>
> The way that code is written, it should fold notifications whose
> processing is still pending so I don't imagine this should flood the queue.
>
> public void notifyChanged(Notification notification)
> {
> if (viewer != null && viewer.getControl() != null &&
> !viewer.getControl().isDisposed())
> {
> // If the notification is an IViewerNotification, it specifies
> how ViewerRefresh should behave. Otherwise fall
> // back to NotifyChangedToViewerRefresh, which determines how
> to refresh the viewer directly from the model
> // notification.
> //
> if (notification instanceof IViewerNotification)
> {
> if (viewerRefresh == null)
> {
> viewerRefresh = new ViewerRefresh(viewer);
> }
>
> * if
> (viewerRefresh.addNotification((IViewerNotification)notifica tion))*
> {
> viewer.getControl().getDisplay().asyncExec(viewerRefresh);
> }
> }
> else
> {
> NotifyChangedToViewerRefresh.handleNotifyChanged(
> viewer,
> notification.getNotifier(),
> notification.getEventType(),
> notification.getFeature(),
> notification.getOldValue(),
> notification.getNewValue(),
> notification.getPosition());
> }
> }
> }
>
> However, I imagine that doing 1000 individual refreshes might be far
> less efficient than just invoking a full refresh for the whole tree.
>
> public void run()
> {
> if (viewer != null && viewer.getControl() != null &&
> !viewer.getControl().isDisposed())
> {
> List<IViewerNotification> current;
>
> synchronized (this)
> {
> current = notifications;
> notifications = null;
> }
>
> if (current != null)
> {
> * for (IViewerNotification viewerNotification : current)*
> {
> refresh(viewerNotification);
> }
> }
> }
> }
>
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417946 is a reply to message #417940] |
Mon, 31 March 2008 11:12 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Jasper,
Yes, I imagine such folding logic could choose some arbitrary threshold
at which it figures the number of incremental updates would incur more
work then a full refresh... Perhaps you could experiment with that to
see how it affects your scenario...
Jasper wrote:
> Ed,
>
> Yes, it is that for-loop that you boldfaced in the second code
> snippet, that is very slow when the number of notifications is large.
>
> As for the folding logic, I didn't really analyze the implementation
> of ViewerRefresh#merge in detail, but shouldn't this logic be able to
> choose one full refresh over several 1,000 calls to
> structuredViewer.update(*)?
>
> Thanks,
> Jasper.
>
>
> Ed Merks wrote:
>> Jasper,
>>
>> The way that code is written, it should fold notifications whose
>> processing is still pending so I don't imagine this should flood the
>> queue.
>>
>> public void notifyChanged(Notification notification)
>> {
>> if (viewer != null && viewer.getControl() != null &&
>> !viewer.getControl().isDisposed())
>> {
>> // If the notification is an IViewerNotification, it specifies
>> how ViewerRefresh should behave. Otherwise fall
>> // back to NotifyChangedToViewerRefresh, which determines how
>> to refresh the viewer directly from the model
>> // notification.
>> //
>> if (notification instanceof IViewerNotification)
>> {
>> if (viewerRefresh == null)
>> {
>> viewerRefresh = new ViewerRefresh(viewer);
>> }
>>
>> * if
>> (viewerRefresh.addNotification((IViewerNotification)notifica tion))*
>> {
>> viewer.getControl().getDisplay().asyncExec(viewerRefresh);
>> }
>> }
>> else
>> {
>> NotifyChangedToViewerRefresh.handleNotifyChanged(
>> viewer,
>> notification.getNotifier(),
>> notification.getEventType(),
>> notification.getFeature(),
>> notification.getOldValue(),
>> notification.getNewValue(),
>> notification.getPosition());
>> }
>> }
>> }
>>
>> However, I imagine that doing 1000 individual refreshes might be far
>> less efficient than just invoking a full refresh for the whole tree.
>>
>> public void run()
>> {
>> if (viewer != null && viewer.getControl() != null &&
>> !viewer.getControl().isDisposed())
>> {
>> List<IViewerNotification> current;
>> synchronized (this)
>> {
>> current = notifications;
>> notifications = null;
>> }
>> if (current != null)
>> {
>> * for (IViewerNotification viewerNotification : current)*
>> {
>> refresh(viewerNotification);
>> }
>> }
>> }
>> }
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417972 is a reply to message #417946] |
Tue, 01 April 2008 06:38 |
Jasper
Messages: 84
Registered: July 2009 |
Member |
|
|
Experiment, yes, but how? The notifications collection inside
ViewerRefresh has default access restriction, so it's not visible in a
derived class. Writing a full replacement for ViewerRefresh isn't
possible either, because AdapterFactoryContentProvider (or my derivative
of it) needs the type to be (or derive from) ViewerRefresh...
Thanks,
Jasper.
Ed Merks wrote:
> Jasper,
>
> Yes, I imagine such folding logic could choose some arbitrary threshold
> at which it figures the number of incremental updates would incur more
> work then a full refresh... Perhaps you could experiment with that to
> see how it affects your scenario...
>
>
> Jasper wrote:
>> Ed,
>>
>> Yes, it is that for-loop that you boldfaced in the second code
>> snippet, that is very slow when the number of notifications is large.
>>
>> As for the folding logic, I didn't really analyze the implementation
>> of ViewerRefresh#merge in detail, but shouldn't this logic be able to
>> choose one full refresh over several 1,000 calls to
>> structuredViewer.update(*)?
>>
>> Thanks,
>> Jasper.
>>
>>
>> Ed Merks wrote:
>>> Jasper,
>>>
>>> The way that code is written, it should fold notifications whose
>>> processing is still pending so I don't imagine this should flood the
>>> queue.
>>>
>>> public void notifyChanged(Notification notification)
>>> {
>>> if (viewer != null && viewer.getControl() != null &&
>>> !viewer.getControl().isDisposed())
>>> {
>>> // If the notification is an IViewerNotification, it specifies
>>> how ViewerRefresh should behave. Otherwise fall
>>> // back to NotifyChangedToViewerRefresh, which determines how
>>> to refresh the viewer directly from the model
>>> // notification.
>>> //
>>> if (notification instanceof IViewerNotification)
>>> {
>>> if (viewerRefresh == null)
>>> {
>>> viewerRefresh = new ViewerRefresh(viewer);
>>> }
>>>
>>> * if
>>> (viewerRefresh.addNotification((IViewerNotification)notifica tion))*
>>> {
>>> viewer.getControl().getDisplay().asyncExec(viewerRefresh);
>>> }
>>> }
>>> else
>>> {
>>> NotifyChangedToViewerRefresh.handleNotifyChanged(
>>> viewer,
>>> notification.getNotifier(),
>>> notification.getEventType(),
>>> notification.getFeature(),
>>> notification.getOldValue(),
>>> notification.getNewValue(),
>>> notification.getPosition());
>>> }
>>> }
>>> }
>>>
>>> However, I imagine that doing 1000 individual refreshes might be far
>>> less efficient than just invoking a full refresh for the whole tree.
>>>
>>> public void run()
>>> {
>>> if (viewer != null && viewer.getControl() != null &&
>>> !viewer.getControl().isDisposed())
>>> {
>>> List<IViewerNotification> current;
>>> synchronized (this)
>>> {
>>> current = notifications;
>>> notifications = null;
>>> }
>>> if (current != null)
>>> {
>>> * for (IViewerNotification viewerNotification : current)*
>>> {
>>> refresh(viewerNotification);
>>> }
>>> }
>>> }
>>> }
>>>
|
|
|
| Re: Workbench event loop stuck after EMF bulk update [message #417979 is a reply to message #417972] |
Tue, 01 April 2008 11:08 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Jasper,
That's kind of dumb; we should change that. You could import the plugin
as source and change the base code. It's also possible to ignore the
viewer refresh field and create your own version entirely...
Jasper wrote:
> Experiment, yes, but how? The notifications collection inside
> ViewerRefresh has default access restriction, so it's not visible in a
> derived class. Writing a full replacement for ViewerRefresh isn't
> possible either, because AdapterFactoryContentProvider (or my
> derivative of it) needs the type to be (or derive from) ViewerRefresh...
>
> Thanks,
> Jasper.
>
>
> Ed Merks wrote:
>> Jasper,
>>
>> Yes, I imagine such folding logic could choose some arbitrary
>> threshold at which it figures the number of incremental updates would
>> incur more work then a full refresh... Perhaps you could experiment
>> with that to see how it affects your scenario...
>>
>>
>> Jasper wrote:
>>> Ed,
>>>
>>> Yes, it is that for-loop that you boldfaced in the second code
>>> snippet, that is very slow when the number of notifications is large.
>>>
>>> As for the folding logic, I didn't really analyze the implementation
>>> of ViewerRefresh#merge in detail, but shouldn't this logic be able
>>> to choose one full refresh over several 1,000 calls to
>>> structuredViewer.update(*)?
>>>
>>> Thanks,
>>> Jasper.
>>>
>>>
>>> Ed Merks wrote:
>>>> Jasper,
>>>>
>>>> The way that code is written, it should fold notifications whose
>>>> processing is still pending so I don't imagine this should flood
>>>> the queue.
>>>>
>>>> public void notifyChanged(Notification notification)
>>>> {
>>>> if (viewer != null && viewer.getControl() != null &&
>>>> !viewer.getControl().isDisposed())
>>>> {
>>>> // If the notification is an IViewerNotification, it
>>>> specifies
>>>> how ViewerRefresh should behave. Otherwise fall
>>>> // back to NotifyChangedToViewerRefresh, which determines
>>>> how
>>>> to refresh the viewer directly from the model
>>>> // notification.
>>>> //
>>>> if (notification instanceof IViewerNotification)
>>>> {
>>>> if (viewerRefresh == null)
>>>> {
>>>> viewerRefresh = new ViewerRefresh(viewer);
>>>> }
>>>>
>>>> * if
>>>>
>>>> (viewerRefresh.addNotification((IViewerNotification)notifica tion))*
>>>> {
>>>>
>>>> viewer.getControl().getDisplay().asyncExec(viewerRefresh);
>>>> }
>>>> }
>>>> else
>>>> {
>>>> NotifyChangedToViewerRefresh.handleNotifyChanged(
>>>> viewer,
>>>> notification.getNotifier(),
>>>> notification.getEventType(),
>>>> notification.getFeature(),
>>>> notification.getOldValue(),
>>>> notification.getNewValue(),
>>>> notification.getPosition());
>>>> }
>>>> }
>>>> }
>>>>
>>>> However, I imagine that doing 1000 individual refreshes might be
>>>> far less efficient than just invoking a full refresh for the whole
>>>> tree.
>>>>
>>>> public void run()
>>>> {
>>>> if (viewer != null && viewer.getControl() != null &&
>>>> !viewer.getControl().isDisposed())
>>>> {
>>>> List<IViewerNotification> current;
>>>> synchronized (this)
>>>> {
>>>> current = notifications;
>>>> notifications = null;
>>>> }
>>>> if (current != null)
>>>> {
>>>> * for (IViewerNotification viewerNotification : current)*
>>>> {
>>>> refresh(viewerNotification);
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 16 23:52:45 GMT 2024
Powered by FUDForum. Page generated in 1.31905 seconds |
] 
Search
Help
Register
Login
Home
