Bug 548760 - Ensure adapters are disposed at once during disposal of a viewer (bulk change)
Summary: Ensure adapters are disposed at once during disposal of a viewer (bulk change)
Status: NEW
Alias: None
Product: GEF
Classification: Tools
Component: GEF MVC (show other bugs)
Version: 5.1.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-28 10:02 EDT by Matthias Wienand CLA
Modified: 2019-09-13 13:41 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Wienand CLA 2019-06-28 10:02:11 EDT
Currently, when a viewer is closed, all parts will subsequently have their parent set to null, which will trigger Viewer.unsetAdapter(part) calls for all of the parts.

This is unacceptable performance-wise, especially for large models. Ideally, all adapters should be disposed and removed at once (in a bulk change) when the viewer is closed.
Comment 1 Mike Marchand CLA 2019-09-13 13:41:54 EDT
To add some more context here... from my post in the GEF5 forums https://www.eclipse.org/forums/index.php?t=post&reply_to=1808682&

!hen I destroy my editor. As each Node's parent is set to null, the InfiniteCanvasViewer calls AdapterSupport.unsetAdapter(). The thing is, AdapterSupport.unsetAdapter() is not a very efficient way to remove 6500 adapters since it walks the list for each adapter that it removes:

// process all keys and remove those pointing to the given adapter
for (AdapterKey<?> key : new HashMap<>(adapters).keySet()) {
	if (adapters.get(key) == adapter) {
		adapters.remove(key);
	}
}


That means a for loop of 6500, then a for loop of 6499 for the next element... and so on, until finally all the adapters have been removed. Interestingly enough, the AdapterSupport method dispose will eventually call adapters.remove() for us anyways. My workaround for this was a little bit unfortunate, needed a custom InfiniteCanvasViewer and a custom AdapterSupport that can be deactivated so that it does not try to "process all keys and remove those pointing to the given adapter" since it is deactivated, we can expect an upcoming disposal, which will do that work much more efficiently for us.