Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 363855 - Very inefficient Marker update
Summary: Very inefficient Marker update
Status: CLOSED FIXED
Alias: None
Product: Acceleo
Classification: Modeling
Component: Core (show other bugs)
Version: 3.1.1   Edit
Hardware: PC Windows Vista
: P3 critical
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 365558
  Show dependency tree
 
Reported: 2011-11-15 13:10 EST by Ed Willink CLA
Modified: 2015-05-27 08:54 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2011-11-15 13:10:19 EST
The Platform API for Marker update is very inefficient; a WorkspaceOperation for each call.

The Acceleo use of this API is therefore very inappropriate; a separate call per attribute per marker.

At one point once my Acceleo edit locked up; precise reason unclear; Visual VM showed no fewer than 13 threads attempting to do Acceleo marker updates, which may be provoking a deadlock.

Please borrow code from org.eclipse.qvt.declarative.editor.ui.builder.MarkerProblemHandler so that all marker changes are aggregated, optimized and submitted as a single WorkspaceOperation. This is particularly important for languages where a single error may provoke thousands of marker changes.
Comment 1 Ed Willink CLA 2011-11-16 07:29:52 EST
I had to kill Eclipse a couple of times while editing Acceleo files. Visual VM showed many threads maintaining markers again.

I therefore think that this is not just a major inefficiency; it's a critical deadlock.

I've reverted to Acceleo 3.1.2 which is much more prectiable in its behaviour; ignore error markers until you Control-S.
Comment 2 Ed Willink CLA 2011-11-24 14:37:52 EST
See bug 358898; it seems every marker change wakes EGIT up.
Comment 3 Stephane Begaudeau CLA 2012-02-16 09:20:27 EST
A fix has been contributed on master and R3_2_maintenance
Comment 4 Stephane Begaudeau CLA 2012-02-16 09:22:49 EST
Marking as resolved.
Comment 5 Laurent Goubet CLA 2015-05-27 08:54:53 EDT
Closing resolved bugs