Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » GEF » GEF5 MVC - Large Model Performance
GEF5 MVC - Large Model Performance [message #1806113] Thu, 02 May 2019 19:48 Go to next message
Mike Marchand is currently offline Mike MarchandFriend
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 #1808224 is a reply to message #1806113] Thu, 20 June 2019 01:39 Go to previous messageGo to next message
Mike Marchand is currently offline Mike MarchandFriend
Messages: 3
Registered: April 2019
Location: Ottawa, Ontario
Junior Member
I would love to get someone's opinion on this.

These same models are loading much more quickly with our GEF3 implementation.
Re: GEF5 MVC - Large Model Performance [message #1808682 is a reply to message #1808224] Fri, 28 June 2019 13:58 Go to previous messageGo to next message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 230
Registered: March 2015
Senior Member
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 #1814600 is a reply to message #1808682] Fri, 13 September 2019 17:54 Go to previous messageGo to next message
Mike Marchand is currently offline Mike MarchandFriend
Messages: 3
Registered: April 2019
Location: Ottawa, Ontario
Junior Member
Hi Matthias!

I'm really happy you got back to me on this topic. I didn't see a notification when you responded, I will have to look into that.

I had to place my GEF5 investigation on hold to continue with my normal development. The migration from GEF3 to GEF5 is a pretty daunting task for our application since it is used fairly heavily in our product.

I opened a bug for [1] and commented on the existing bug for [2].
Re: GEF5 MVC - Large Model Performance [message #1814818 is a reply to message #1814600] Thu, 19 September 2019 07:21 Go to previous message
Matthias Wienand is currently offline Matthias WienandFriend
Messages: 230
Registered: March 2015
Senior Member
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
Previous Topic:GEF 5.2.0 is released!
Next Topic:Generate a tree node with icon and multiline text using GEF
Goto Forum:
  


Current Time: Thu Oct 28 01:35:11 GMT 2021

Powered by FUDForum. Page generated in 0.01990 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top