Expanding AADL element in the AADL naviator is very slow

[lwrage]

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]

I can definitely reproduce this.

[AaronGreenhouse]

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]

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]

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]

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]

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]

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

[AaronGreenhouse]

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.