| Well, sort of, but we actually have customers out there building real products on IMP, so from their perspective it's not too early.
Of course I'd rather not have to do this, but I don't think we have a choice if we want to keep some of our existing users happy. On Apr 6, 2010, at 11:13 AM, Jurgen Vinju wrote: 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/jurgenvinjuskype: jurgen.vinju _______________________________________________ imp-dev mailing list imp-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/imp-dev
-- Cheers, - Bob ------------------------------------------------- Robert M. Fuhrer Research Staff Member Programming Technologies Dept. IBM T.J. Watson Research Center
|
