Re: [imp-dev] Small API change needed to improve performance of message/

}

But this would also be a good time to ask:

If you've implemented IMessageHandler yourselves, what was the reason?

I.e., perhaps there's some additional functionality we should have on such an extension interface, while we're at it...

On Apr 6, 2010, at 9:47 AM, Robert M. Fuhrer wrote:

Hi Everyone,

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.

Proposed IMP API change:

To achieve the full improvement described above, though, requires a small API change to IMP's IMessageHandler interface, which doesn't presently have an API call to notify when the producer of messages is finished producing messages from a parsing/analysis session.

In particular, I'd like to add the following method:

  public interface IMessageHandler {
     // ...
     /**
   * Marks the end of a session of messages.
   */
     void endMessages();
   // ...
  }

Now, most of the implementations of IMessageHandler that I'm aware of are in IMP itself, which consumes the diagnostic output of an IParseController implementation. So, I'd expect that the impact of such an API change would be negligible, if anything.

That said, technically, this would be a breaking API change, so I need to ask you all whether this will cause you any problem.

Comments?

Cheers,

- Bob

-------------------------------------------------

Robert M. Fuhrer

Research Staff Member

Programming Technologies Dept.

IBM T.J. Watson Research Center

IMP Project Lead (http://www.eclipse.org/imp)

X10: Productivity for High-Performance Parallel Programming (http://x10-lang.org)