| Hi Ed,
That's a good question - it's definitely similar-looking from a high enough altitude, and obviously both entities are IMessageHandler implementations.
On the other hand, the annotation API is quite different from the marker API, enough that the code that talks to IAnnotationModelExtension is much smaller and simpler, compared to MarkerCreatorWithBatching. So, yes, we can create a common base class, but it probably wouldn't save/share much code.
I'll give it a shot though and see what results.
That said, while dealing with the annotation performance issue, I have glanced at MarkerCreatorWithBatching and wondered whether it could be slimmed down a bunch, even by itself... On Apr 6, 2010, at 12:33 PM, Ed Willink wrote: 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:
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
|
