Quite annoying for big files. Seems to be an Eclipse “feature” if you configure your error markers to show up in the problems view. Need better support for handling the (stupid) decolorization events Eclipse fires when updating the error markers.

Submitted by Lennart Kats on 2 March 2010 at 12:52

They’ve been struggling with this problem in IMP as well for a while (although I don’t use their API for reporting errors).

Quoting from the mailing list:

Problem:

I just did some performance diagnosis/tuning work relating to https://bugs.eclipse.org/bugs/show_bug.cgi?id=281359. In a nutshell, when there were many error annotations on a source file, say, many dozens or hundreds, the editor became unusably slow.

Diagnosis:

The main problem was that each message produced by IParseController.parse() was directly applied as an "annotation model" update, via calls to Eclipse JFace text API methods. Since UI updates are driven by annotation model listeners, this approach caused many unnecessary UI updates; hence the slowdown.

Solution:

Luckily, I've discovered an extension to the IAnnotationModel interface IAnnotationModelExtension, which has extra API calls that allow you to submit a group of annotation changes as a single batch. The result is that rather than updating the model, and most importantly, all the annotation model listeners, with each new Annotation, this cycle happens just once. The performance improvement is rather dramatic: orders of magnitude.

So we should probably do something similar in AstMessageHandler?

A related bug (https://bugs.eclipse.org/bugs/show_bug.cgi?id=245296) notes that this results from slow performance Marker.setAttributes(), which spawns off a workspace thread for each operation it performs. We should batch up all these calls in a single workspace job.

Fixed in 0.4.3 with a new helper class that blocks the AnnotationPainter before the parser completes.