Eclipse Community Forums: EMF » emf batch delete very slow

Home » Modeling » EMF » emf batch delete very slow

emf batch delete very slow [message #427068]

Fri, 30 January 2009 11:13

Eclipse User

I have a tableViewer (SWT.VIRTUAL) with about 20000 rows. The table is
backed by a AdapterFactoryContentProvider. If I select all and delete, it
takes too long, like one row per second.

Through debugger, I can see after an object is deleted from EList, the
tableViewer is notified and it is searching linearly through table items
to find the deleted object. Then does an update. That is probably why is
taking so long for 20000 rows.

Any tips are appreciated. I will try to turn off viewer updates until the
end. But not sure how to do it.

Thanks,
John

Re: emf batch delete very slow [message #427069 is a reply to message #427068]

Fri, 30 January 2009 13:25

Eclipse User

John,

There was a similar question earlier in the week. At that time I
suggested they look what's happening in
AdapterFacotoryContentProvider.ViewerRefresh.merge. I would expect this
would merge the notifications. I don't recall if there was a response
to the suggestion...

John Ye wrote:
>
> I have a tableViewer (SWT.VIRTUAL) with about 20000 rows. The table is
> backed by a AdapterFactoryContentProvider. If I select all and delete,
> it takes too long, like one row per second.
>
> Through debugger, I can see after an object is deleted from EList, the
> tableViewer is notified and it is searching linearly through table
> items to find the deleted object. Then does an update. That is
> probably why is taking so long for 20000 rows.
>
> Any tips are appreciated. I will try to turn off viewer updates until
> the end. But not sure how to do it.
>
> Thanks,
> John
>
>
>

Re: emf batch delete very slow [message #427070 is a reply to message #427069]

Fri, 30 January 2009 15:00

Eclipse User

Ed,

Thanks for the tip. I will give a try tonight. I guess I probably need to
override some ViewerRefresh implementation to avoid table viewer updates.

Thanks,
John

Re: emf batch delete very slow [message #427078 is a reply to message #427069]

Fri, 30 January 2009 23:54

Eclipse User

Hi Ed,

It turned out NotifyChangedToViewerRefresh.handleNotifyChanged is used
instead of viewerRefresh.

I was following the recipe you posted on

http://webui.sourcelabs.com/eclipse/issues/207324

that generates table columns using properties and PropertyEditingSupport.
It is very cool. I also followed your EMF book (1st edition) 14.2.3 to add
intermediary view objects for lists in my model.

If I remove the intermediary objects, delete all doesn't take long. It
seems that the intermediary listens to EList directly so each remove(i)
causes viewer to update.

By the way, when there is no intermediary, most of the time is spent in
UniqueEList.add function called by DeleteCommand.execute function. I
wonder why not use a HashSet.

Thanks,
John

Re: emf batch delete very slow [message #427083 is a reply to message #427078]

Sat, 31 January 2009 07:56

Eclipse User

John,

HashSets have random ordering when you iterate over them, but it seems a
LinkedHashSet ought to work well. Feel free to open a bugzilla
enhancement request.

John Ye wrote:
>
> Hi Ed,
>
> It turned out NotifyChangedToViewerRefresh.handleNotifyChanged is used
> instead of viewerRefresh.
> I was following the recipe you posted on
>
> http://webui.sourcelabs.com/eclipse/issues/207324
>
> that generates table columns using properties and
> PropertyEditingSupport. It is very cool. I also followed your EMF book
> (1st edition) 14.2.3 to add intermediary view objects for lists in my
> model.
>
> If I remove the intermediary objects, delete all doesn't take long. It
> seems that the intermediary listens to EList directly so each
> remove(i) causes viewer to update.
>
> By the way, when there is no intermediary, most of the time is spent
> in UniqueEList.add function called by DeleteCommand.execute function.
> I wonder why not use a HashSet.
>
> Thanks,
> John
>
>
>
>
>
>

Re: emf batch delete very slow [message #427096 is a reply to message #427083]

Sun, 01 February 2009 23:49

Eclipse User

I logged eclipse ticket number 263175 for DeleteCommand.execute using
UniqueEList.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=263175

For my main problem, I overrode AdapterFactoryContentProvider's
notifyChanged function to create a ViewNotification if notification is not
an instance of IViewerNotification.

It seems to work OK, but I did run into a couple of null pointer warnings.

public void notifyChanged(Notification notification) {
if (viewer != null && viewer.getControl() != null &&
!viewer.getControl().isDisposed()) {
if (viewerRefresh == null) {
viewerRefresh = new ViewerRefresh(viewer);
}

if (notification instanceof IViewerNotification) {
} else {
notification = new ViewerNotification(notification);
}

if (viewerRefresh.addNotification((IViewerNotification) notification)) {
viewer.getControl().getDisplay().asyncExec(viewerRefresh);
}
}
}

Suggestions are appreciated.

Thanks,
John

Re: emf batch delete very slow [message #427104 is a reply to message #427096]

Mon, 02 February 2009 07:47

Eclipse User

John,

Comments below.

John Ye wrote:
>
> I logged eclipse ticket number 263175 for DeleteCommand.execute using
> UniqueEList.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=263175
I've committed the change.
>
> For my main problem, I overrode AdapterFactoryContentProvider's
> notifyChanged function to create a ViewNotification if notification is
> not an instance of IViewerNotification.
>
> It seems to work OK, but I did run into a couple of null pointer
> warnings.
> public void notifyChanged(Notification notification) {
> if (viewer != null && viewer.getControl() != null &&
> !viewer.getControl().isDisposed()) {
> if (viewerRefresh == null) {
> viewerRefresh = new ViewerRefresh(viewer);
> }
>
> if (notification instanceof IViewerNotification) {
> } else {
> notification = new ViewerNotification(notification);
> }
>
> if (viewerRefresh.addNotification((IViewerNotification)
> notification)) {
>
> viewer.getControl().getDisplay().asyncExec(viewerRefresh);
> }
> }
> }
>
> Suggestions are appreciated.
Why not just do an instanceof test, create the ViewerNotification if
needed, and call super to avoid duplicating any logic?
>
> Thanks,
> John
>

Re: emf batch delete very slow [message #427111 is a reply to message #427104]

Mon, 02 February 2009 10:23

Eclipse User

Ed,

You are right. The logic can be simplified by calling super implementation:

public void notifyChanged(Notification notification) {

if (notification instanceof IViewerNotification) {
}
else {
notification = new ViewerNotification(notification);
}
super.notifyChanged(notification);
}

I am not sure if there are side effects of always using a
ViewerNotification.

Thanks,
John

Ed Merks wrote:

> John,

> Comments below.

> John Ye wrote:
>>
>> I logged eclipse ticket number 263175 for DeleteCommand.execute using
>> UniqueEList.
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=263175
> I've committed the change.
>>
>> For my main problem, I overrode AdapterFactoryContentProvider's
>> notifyChanged function to create a ViewNotification if notification is
>> not an instance of IViewerNotification.
>>
>> It seems to work OK, but I did run into a couple of null pointer
>> warnings.
>> public void notifyChanged(Notification notification) {
>> if (viewer != null && viewer.getControl() != null &&
>> !viewer.getControl().isDisposed()) {
>> if (viewerRefresh == null) {
>> viewerRefresh = new ViewerRefresh(viewer);
>> }
>>
>> if (notification instanceof IViewerNotification) {
>> } else {
>> notification = new ViewerNotification(notification);
>> }
>>
>> if (viewerRefresh.addNotification((IViewerNotification)
>> notification)) {
>>
>> viewer.getControl().getDisplay().asyncExec(viewerRefresh);
>> }
>> }
>> }
>>
>> Suggestions are appreciated.
> Why not just do an instanceof test, create the ViewerNotification if
> needed, and call super to avoid duplicating any logic?
>>
>> Thanks,
>> John
>>

Re: emf batch delete very slow [message #427115 is a reply to message #427111]

Mon, 02 February 2009 12:00

Eclipse User

John,

The design is how it currently is because ViewerNotification was added
later so you'd only have them if you regenerated your *.edit projects.
So we decided to leave existing behavior just as it was so that existing
applications would definitely be unaffected. So I wouldn't anticipate
any problems from what you've done.

John Ye wrote:
>
> Ed,
>
> You are right. The logic can be simplified by calling super
> implementation:
>
> public void notifyChanged(Notification notification) {
>
> if (notification instanceof IViewerNotification) {
> } else {
> notification = new ViewerNotification(notification);
> }
> super.notifyChanged(notification);
> }
>
> I am not sure if there are side effects of always using a
> ViewerNotification.
>
> Thanks,
> John
>
>
> Ed Merks wrote:
>
>> John,
>
>> Comments below.
>
>> John Ye wrote:
>>>
>>> I logged eclipse ticket number 263175 for DeleteCommand.execute
>>> using UniqueEList.
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=263175
>> I've committed the change.
>>>
>>> For my main problem, I overrode AdapterFactoryContentProvider's
>>> notifyChanged function to create a ViewNotification if notification
>>> is not an instance of IViewerNotification.
>>>
>>> It seems to work OK, but I did run into a couple of null pointer
>>> warnings.
>>> public void notifyChanged(Notification notification) {
>>> if (viewer != null && viewer.getControl() != null &&
>>> !viewer.getControl().isDisposed()) {
>>> if (viewerRefresh == null) {
>>> viewerRefresh = new ViewerRefresh(viewer);
>>> }
>>>
>>> if (notification instanceof IViewerNotification) {
>>> } else {
>>> notification = new ViewerNotification(notification);
>>> }
>>>
>>> if (viewerRefresh.addNotification((IViewerNotification)
>>> notification)) {
>>>
>>> viewer.getControl().getDisplay().asyncExec(viewerRefresh);
>>> }
>>> }
>>> }
>>>
>>> Suggestions are appreciated.
>> Why not just do an instanceof test, create the ViewerNotification if
>> needed, and call super to avoid duplicating any logic?
>>>
>>> Thanks,
>>> John
>>>
>
>

Re: emf batch delete very slow [message #427122 is a reply to message #427111]

Mon, 02 February 2009 14:21

Eclipse User

Ed,

Thanks a lot for your help!

Best,
John

Previous Topic:	[Teneo] Use of constrained=true for 1 to 1?
Next Topic:	generate an rcp application with emf

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 16 06:43:22 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter