Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [imp-dev] Small API change needed to improve performance of message/annotation handling
Hi

Isn't this the 'same' problem as I solved in https://bugs.eclipse.org/bugs/show_bug.cgi?id=245296 and which Stan implemented by introducing of MarkerCreatorWithBatching?

Shouldn't the revised API at least be compatible and so provide flush(IProgressMonitor) rather than endMessages()?

Since there is so much shared functionality perhaps an AbstractMessageHandler (with optional batching) is needed.

    Regards

        Ed Willink

On 06/04/2010 14:47, 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 Team Lead (http://www.eclipse.org/imp)
X10: Productivity for High-Performance Parallel Programming (http://x10-lang.org)
 


_______________________________________________
imp-dev mailing list
imp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/imp-dev
  


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.800 / Virus Database: 271.1.1/2793 - Release Date: 04/05/10 19:32:00

Back to the top