Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 363855

Summary:	Very inefficient Marker update
Product:	[Modeling] Acceleo	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	Project Inbox <acceleo-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	critical
Priority:	P3	CC:	stephane.begaudeau
Version:	3.1.1
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Whiteboard:
Bug Depends on:
Bug Blocks:	365558

Description Ed Willink

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

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

2011-11-24 14:37:52 EST

See bug 358898; it seems every marker change wakes EGIT up.

Comment 3 Stephane Begaudeau

2012-02-16 09:20:27 EST

A fix has been contributed on master and R3_2_maintenance

Comment 4 Stephane Begaudeau

2012-02-16 09:22:49 EST

Marking as resolved.

Comment 5 Laurent Goubet

2015-05-27 08:54:53 EDT

Closing resolved bugs