Community
Participate
Working Groups
During investigation bug 474115, I realized OverviewRuler.doPaint is extremly slow. It iterate over all (filtered to type) annotations: 1. As many time as many types are enabled 2. For each enabled annotation collect it position, and for each one annotationmodel lock have to be obtained It's extremely slow, and if during repaint our occurences finder obtain lock, editor become extremely laggy.
Dawid, please provide Gerrit.
It's not simple change. After "desynchronize" it's a little bit better but now eclipse stuck on GC operations. OverviewRuler for each enabled Annotation: 1. Collect Color 2. Draw rectangle 3. Fill rectanle 4. Call getLineAtOffset 5. Set width 6. Draw line I have ~ 100 000 annotations on my test file. It's extremely slow.... Rather than rewriting boxes, they should be overwritten/calculated at once. I'm not best in drawing, especially with GC, so this might take much more time.
I prepared PoC code but it simply raise another problem: CompilationUnitDocumentProvider and it's "CompilationUnitAnnotationModel" (DLTK have same implmentation, probably other *DT too) and how it play with Annotation. Each annotation is registered twice, normally (using standard annotationmodel), and in ReverseMap that is used to map Position to Annotations. This structure is later used to mark resource marker annotations as fixed (gray icons). Any additional problem is slower than previous (see ReverseMap.put implementation). So if CompilationUnit have many annotations reported (problems, warnings, occurencies) this extends reporting a lot. I don't think that all annotations have to be collected in reverse order (first optimization point), I also belive that future mapping could be done in more efficient way. Any ideas? This one probably should throwed to JDT team ;)
