Bug 442131 - The "Model Explorer" filter can hang Eclipse indefinitly with large modeling projects
Summary: The "Model Explorer" filter can hang Eclipse indefinitly with large modeling ...
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 1.0.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance, triaged
Depends on: 442337
Blocks:
  Show dependency tree
 
Reported: 2014-08-20 03:44 EDT by Pierre-Charles David CLA
Modified: 2014-10-06 10:14 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 Pierre-Charles David CLA 2014-08-20 03:44:56 EDT
When at least one large session or modeling project is opened in the workspace, trying to use the filter embedded in the "Model Explorer" view blocks the Eclipse UI for so long that nothing can be done except forcibly killing the whole Eclipse process, losing any unsaved work.

In my test on a session with 114MB of combined data (70MB in an aird file, the rest in semantic models), the UI is completely blocked for several minutes with one CPU core constantly at 100% for the whole time. I abandonned and killed it after about 4 minutes.
Comment 1 Pierre-Charles David CLA 2014-08-21 04:30:22 EDT
Profiling shows that 97% of the time is spent in DAnalysisSessionServicesImpl.getRepresentationData(), via SiriusCommonContentProvider.getChildren which is called by CNF.
Comment 2 Pierre-Charles David CLA 2014-08-21 05:48:21 EDT
A quick measure using System.nanoTime() shows that on an the sample model used, a single call to AnalysisSessionServicesImpl.getRepresentationData() takes about 8ms at the beginning, and drop to 4 or 5ms after a while (probably after the JIT takes effect).

This is both a lot for what the code does (iterating over a list of about 10k DRepresentations and testing their getTarget() for identity, not even equality), and small compared to the slowness we see in the several tickets where this method appears in the profile. It looks like simply optimizing this method by itself will not get us the performance we want. We will also need to fix all the problemtic call patterns which invoke it much too often.

When commenting out all the code in getRepresentationData() (returning en empty collection), trying to use the Model Explorer filter with the sample model still blocks the whole UI for about 45s, so we will need something more for this specific issue. Some ideas:
1. optimize the implementation of SiriusCommonContentProvider.hasChildren(Object), which is called a lot by CNF but recomputes the complete getChildren() result each time.
2. see if we can change the way CNF calls us to batch or cache some computations.
3. see if the bulk of the filtering work can be done in a background job out of the UI thread.
Comment 3 Pierre-Charles David CLA 2014-09-11 11:05:24 EDT
From several minutes initially, I'm down to about 3 or 4 seconds to filter the same project. I'm reducing the severity, but keeping the ticket open because the fact that this blocks the UI thread is still a problem.