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

[Jurgen Vinju <jurgen@xxxxxxxxx>]

Dear Bob,

I think it's a bit early in IMP's lifetime to have extension interfaces.

Cheers,

Jurgen

On Tue, Apr 6, 2010 at 4:48 PM, Robert M. Fuhrer <rfuhrer@xxxxxxxxxxxxxx> wrote:
> After discussing this with a colleague a bit, I realized that of course we
> can simply introduce an extension interface housing the extra method,
> thereby preserving backward compatibility. The new interface would simply
> be:
>   public IMessageHandlerExtension extends IMessageHandler {
>       void endMessages();
>   }
>
> 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)
>
> _______________________________________________
> imp-dev mailing list
> imp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/imp-dev
>
>



-- 
Jurgen Vinju
- Centrum Wiskunde & Informatica - SEN1
- INRIA Lille - ATEAMS
- Universiteit van Amsterdam

  www: http://jurgen.vinju.org,
http://www.rascal-mpl.nl,http://twitter.com/jurgenvinju
skype: jurgen.vinju