Bug 562286

Summary:	OverviewRuler iterate over annotations in inefficient and danger way
Product:	[Eclipse Project] Platform	Reporter:	Dawid Pakula <zulus>
Component:	Text	Assignee:	Platform-Text-Inbox <platform-text-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	daniel_megert, Lars.Vogel
Version:	4.15
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:
Bug Depends on:	562688
Bug Blocks:	474115

Description Dawid Pakula

2020-04-18 17:17:15 EDT

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.

Comment 1 Lars Vogel

2020-04-18 17:33:17 EDT

Dawid, please provide Gerrit.

Comment 2 Dawid Pakula

2020-04-18 19:01:39 EDT

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.

Comment 3 Dawid Pakula

2020-04-19 05:28:09 EDT

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 ;)