Summary: | The "Model Explorer" filter can hang Eclipse indefinitly with large modeling projects | ||
---|---|---|---|
Product: | [Modeling] Sirius | Reporter: | Pierre-Charles David <pierre-charles.david> |
Component: | Core | Assignee: | Project inbox <sirius.core-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | laurent.redor |
Version: | 1.0.0 | Keywords: | performance, triaged |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | 442337 | ||
Bug Blocks: |
Description
Pierre-Charles David
2014-08-20 03:44:56 EDT
Profiling shows that 97% of the time is spent in DAnalysisSessionServicesImpl.getRepresentationData(), via SiriusCommonContentProvider.getChildren which is called by CNF. 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. 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. |