| GEF5 MVC - Large Model Performance [message #1806113] |
Thu, 02 May 2019 19:48  |
 Mike Marchand
Messages: 3
Registered: April 2019
Location: Ottawa, Ontario |
Junior Member |
|
|
I am using GEF 5.0.2 MVC and MVC.UI. I have a fairly large model of 6500 nodes and I am encountering some performance issues loading and unloading my model into GEF.
When I profile my application with YourKit, I am spending 205 seconds in setViewerContents(), 188s of which is spent in InfiniteCanvasViewer.getAdapter().
The two functions that are calling InfiniteCanvasViewer.getAdapter() excessively are ContentBehavior.getContentPartFactory() (spent 89s) and ContentBehavior.getContentPartPool() (spent 87s).
Has anyone else encountered this problem? I have some ideas to work around the problem with custom ContentBehavior and caching, but I would like to see if perhaps we might be able to optimize this behavior in GEF.
The second issue that I have is when 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.
|
|
|
|
| Re: GEF5 MVC - Large Model Performance [message #1808682 is a reply to message #1808224] |
Fri, 28 June 2019 13:58  |
|
Hi Mike,
I want to answer both issues separately.
1) content-part-synchronisation (and its performance)
We already put some work into this. A colleague of mine ensured that all parts will be removed/added in as few operations as possible, i.e. addChildren(), removeChildren() etc. will be used instead of addChild(), removeChild() etc..
However, we could cache the ContentPartPool and the ContentPartFactory in order to speed it up some more. They could be determined during activation, for example.
I believe that we do need to put more work into optimising the performance here. However, it will have to be dealt with over time.
Would you please create a Bugzilla ticket for this optimisation? [1]
2) closing an editor
The implementation of unsetAdapter() should not be changed since it is working correctly. However, as you already figured, it was not intended to be used for removal of all adapters (in the case of disposal) but never tested. We need to ensure that dispose() is used to clear all adapters at once.
I am not yet sure how the control flow is to be adjusted in order to make this work. At which time do you disable the support? I created a Bugzilla describing the problem. [2]
[1] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=GEF
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=548760
Best regards,
Matthias
[Updated on: Fri, 28 June 2019 14:03] Report message to a moderator |
|
|
|
| Re: GEF5 MVC - Large Model Performance [message #1814818 is a reply to message #1814600] |
Thu, 19 September 2019 07:21 |
|
Thanks for reporting! Let us continue the discussion on the Bugzilla.
I still have to do the Eclipse CI migration (HIPP to JIRO, first enable ci-staging and make it work, then disable HIPP and turn ci-staging into ci). After that I can look into the issues (if they are not solved by someone else in the meantime ;-).
Best regards,
Matthias
|
|
|
Powered by
FUDForum. Page generated in 0.03981 seconds
] 
Search
Help
Register
Login
Home
