Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expanding AADL element in the AADL naviator is very slow #2430

Closed
lwrage opened this issue Sep 2, 2020 · 8 comments · Fixed by #2470
Closed

Expanding AADL element in the AADL naviator is very slow #2430

lwrage opened this issue Sep 2, 2020 · 8 comments · Fixed by #2470
Assignees
Milestone

Comments

@lwrage
Copy link
Contributor

lwrage commented Sep 2, 2020

Summary

Expanding a public package section with 100 classifiers takes more than 10s (when done for the first time after restart). Expanding a system instance with 1000 modes takes longer than I was willing to wait.

Investigate what takes so long.

We should also limit the number of child nodes shown in the navigator and generally exclude SOMs.

It may be that we read a resource again and again during expansion. Also need to check if we hold on to resources. I notices significant memory usage when expanding a large instance model.

Environment

  • OSATE Version: 2.8.0
  • Operating System: Windows
@AaronGreenhouse
Copy link
Contributor

I can definitely reproduce this.

@AaronGreenhouse
Copy link
Contributor

AaronGreenhouse commented Sep 25, 2020

So far I have been able to isolate the problem to Aadl2QualifiedNameFragmentProvider.getFragment(), but I still do not know why this is slow. I've looked at other places that seem more obvious, like the looking up of the resource, climbing up and down the parse tree, and building and copying strings redundantly, and those are not the problem.

THis is mehtod is called as a result of EObjectURIWrapper calling EcoreUtil.getURI(), which calls XtextResource.getURIFragment(), which calls Aadl2QualifiedNameFragmentProvider.getFragment()

@AaronGreenhouse
Copy link
Contributor

Urgh. Was going about this wrong. I thought the slowness might be in the computation of the children via AadlElementContentProvider.getChildren(). But that is not the problem. Delay occurs after the children have been computed and returned.

@AaronGreenhouse
Copy link
Contributor

I feel stupid, I should have checked this first. The problem is the AadlElementLabelProvider, the getImage() and getText() methods, which for each element of tree cause the URI in the EObjectURIWrapper to be resolved, which parses the file. SO each item in the tree causes 2 parses.

Now, building the tree itself with 100s of elements is noticeable as well. If I change getImage() to return null and getText to return bob, I still have to wait about a second for the tree to expand, but I don't get a spinning cursor a wait for many seconds.

@AaronGreenhouse
Copy link
Contributor

Why do we use EObjectURIWrapper? What is the problem with holding one to the EObjects themselves? Is the problem that you don't want browsing the navigator to force .aadl files to stay loaded?

@AaronGreenhouse
Copy link
Contributor

It's easy enough to limit the number of children generated by throwing in a call to limit() in the stream in AadlElementContextProvider.getChildren()

		return children.limit(100).map(element -> new EObjectURIWrapper(element)).toArray();

@AaronGreenhouse
Copy link
Contributor

We should zoom tomorrow to discuss what we want to do where.

@AaronGreenhouse
Copy link
Contributor

After zoom call with @lwrage and @joeseibel we decided the following:

  • The EObjectUriWrapper should hold the label and image and that should be set up at creation time
  • Instance Models should not show the SOMs in the navigator
  • In general the number of children should be limited to 100 children or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants