Home » Eclipse Projects » Eclipse Platform » Workbench event loop stuck after EMF bulk update
Workbench event loop stuck after EMF bulk update [message #326553] |
Tue, 25 March 2008 07:10 ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Jasper![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=jasper.noid%40yahoo.com) 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 #326566 is a reply to message #326553] |
Tue, 25 March 2008 12:26 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: merks.ca.ibm.com
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 #326580 is a reply to message #326566] |
Tue, 25 March 2008 16:46 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Jasper![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=jasper.noid%40yahoo.com) 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 #326586 is a reply to message #326580] |
Tue, 25 March 2008 18:20 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: merks.ca.ibm.com
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 #326673 is a reply to message #326586] |
Fri, 28 March 2008 05:36 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Jasper![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=jasper.noid%40yahoo.com) 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 #326674 is a reply to message #326673] |
Fri, 28 March 2008 07:36 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Jasper![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=jasper.noid%40yahoo.com) 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 #326681 is a reply to message #326674] |
Fri, 28 March 2008 12:11 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: merks.ca.ibm.com
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>
|
|
|
Re: Workbench event loop stuck after EMF bulk update [message #326717 is a reply to message #326681] |
Mon, 31 March 2008 08:34 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Jasper![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=jasper.noid%40yahoo.com) 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 #326723 is a reply to message #326717] |
Mon, 31 March 2008 11:12 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: merks.ca.ibm.com
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 #326770 is a reply to message #326723] |
Tue, 01 April 2008 06:38 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) ![Go to next message Go to next message](theme/Solstice/images/down.png) |
Jasper![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=jasper.noid%40yahoo.com) 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 #326777 is a reply to message #326770] |
Tue, 01 April 2008 11:08 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
Eclipse User![Friend of Eclipse Friend](/donate/web-api/friends_decorator.php?email=) |
|
|
|
Originally posted by: merks.ca.ibm.com
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);
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
|
|
|
Goto Forum:
Current Time: Sun Sep 01 02:21:34 GMT 2024
Powered by FUDForum. Page generated in 0.04446 seconds
|