Home » Modeling » EMF » ECollections.setEList() does not minimize notifications
| ECollections.setEList() does not minimize notifications [message #424293] |
Wed, 22 October 2008 12:14  |
 Sebastian Paul
Messages: 106
Registered: July 2009 |
Senior Member |
|
|
Hi,
I was just confronted with the method
org.eclipse.emf.common.util.ECollections.setEList(EList<T>, List<? extends
T>)
At the end, the list is truncated by removing one item after another,
causing one notification for each item.
Instead, removeAll() should be used, since it creates just one single
notification of type ADD_MANY:
eList.removeAll(eList.subList(index, eList.size() - 1);
Of course this requires building the subList, but the goal is minimizing
notifications.
Or are there reasons not to do this?
Kind regards, Sebastian
|
|
|
| Re: ECollections.setEList() does not minimize notifications [message #424296 is a reply to message #424293] |
Wed, 22 October 2008 12:26  |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
Comments below.
Sebastian Paul wrote:
> Hi,
> I was just confronted with the method
> org.eclipse.emf.common.util.ECollections.setEList(EList<T>, List<?
> extends T>)
>
> At the end, the list is truncated by removing one item after another,
> causing one notification for each item. Instead, removeAll() should be
> used, since it creates just one single notification of type ADD_MANY:
> eList.removeAll(eList.subList(index, eList.size() - 1);
I'm not sure how this would behave if the list has duplicates...
>
> Of course this requires building the subList, but the goal is
> minimizing notifications.
We don't really minimize the other adds and removes up to that point.
One might argue that we should...
>
> Or are there reasons not to do this?
The duplicates issue would concern me, but eList.subList(index,
eList.size() - 1).clear() should work though, right?
>
> Kind regards, Sebastian
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: ECollections.setEList() does not minimize notifications [message #424302 is a reply to message #424301] |
Wed, 22 October 2008 15:46 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
Good point. It would just use an iterator and be no better. We can't
make any assumptions about the implementation class behavior, so that
doesn't help. We could specialize removeRange to be similar to how
removeAll is specialized. That would definitely help, in combination
with clearing the subList. But the rest of the adds and removes aren't
optimized for producing ADD_MANY and REMOVE_MANY. It looks like quite a
bit of work to do all that optimally... I suppose it's reasonable to
argue the work would be done only once whereas the cost of suboptimal
notifications scale. The logic involved in minimizing the number of
modifications and hence notifications will definitely be slower though...
Sebastian Paul wrote:
>>> The duplicates issue would concern me, but eList.subList(index,
>>> eList.size() - 1).clear() should work though, right?
>> Sure, but as far as I can see, it would also cause notifications for
>> each removed item.
> Maybe some ELists should overwrite
> java.util.AbstractList.removeRange(int, int)?
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 02:01:34 GMT 2024
Powered by FUDForum. Page generated in 0.03499 seconds |
] 
Search
Help
Register
Login
Home
