Latest revision as of 04:13, 7 September 2011

Evolution Specification: Improvements of the Acceleo Parser

Current status is DRAFT

Preamble

This page will be used to discuss the evolution of the Acceleo parser.

The possible status are (roughly inspired by PEP-0001):

• DRAFT: Initial version and revisions based on internal feedback and discussions. DRAFT versions should never be made available outside of Obeo. They have version numbers 0.x.
• PROPOSAL: When the document is considered ready for discussion with the client, it becomes a PROPOSAL. The first such version is numbered 1.0. Feedback from the client are integrated in further versions 1.x which are still PROPOSALs. Changes from one version to the next should be documented inside the document (as the client does not have access to the source repository).
• ACCEPTED: Once agreement has been reached with the client, the document becomes ACCEPTED.This version becomes the authoritative one for guiding the evolution's actual implementation. It should normally be considered freezed. Any change to it should be exceptional and subject to approval by the project manager. Such changes must be clearly documented and justified.
• ARCHIVED: Once the evolution has been implemented _and_ its specification has been integrated into the reference documentation, this document is ARCHIVED. Any further change to the same features should be another Viewpoint Evolution .

Relevant tickets

• Bug 350219 - Introduce a cache to improve performances of the compilation and the tooling

Introduction

Several solutions are considered to improve the performances of the Acceleo Parser:

• introduction of Google Collection based caches
• removal of the CST in the parser
• improved the incremental compilation to minimize the recompilation of Acceleo modules
• usage of logical resources to prevent useless loading of emtl files

Detailed Specification

Google Collection based caches

Google collection based caches could prevent several useless loading of previously compiled emtl files used to resolve links during the compilation. This improvement could also be used in the tooling to improve several mechanisms:

• parser
• completion
• open declaration
• search
• refactoring

Removal of the CST

The removal of the CST would suppress lot of redundancy in the Acceleo parser, it may produce a minimal improvement on the performances of the parsing but it would be very valuable in order to improve the parser. With only one structure manipulated (the AST), we wouldn't have to do some jobs twice in the parser and in the tooling. This change would introduce several internal and external API break in the parser and the ui. The following components would be affected:

• parser (external API)
• completion (use of internal API of the parser)
• open declaration (use of internal API of the parser)
• search (use of internal API of the parser)
• refactoring (use of internal API of the parser)

Logical resources

Logical resources would be of a great help with the Google collections based cache in order to prevent useless loading of emtl files. This mechanism would improve not only the parser but also the following components:

• completion
• open declaration
• search
• refactoring

Smaller emtl files

Changes have been made to reduce the size of emtl files by trimming useless signature from the OCL context once compiled. This change that has been contributed creates smaller emtl files but it does not affect the performances of the compilation time. We could also remove the positions from the emtl files but it would lessen the precision of the stack traces created by the engine and it could create problems for the refactoring, and the open declaration.

Improved incremental compilation

We could also improve the incremental compilation to recompile only the body of a module element if only the body of this module element has changed. This change would introduce potential gaps between the positions serialized in emtl files and the real positions of the element in the Acceleo module. We could try to correct the positions by hand or we could remove the positions from the emtl files. This change would produce a massive impact on the performances of the compilation but it could have side effects on the mechanism of the tooling that are relying on the positions:

• refactoring
• search
• ctrl+click

Backward Compatibility and Migration Paths

All the mentioned changes should not in any way affect the backward compatibility for those who have created an Acceleo generator. An Acceleo module created with the proposed improvements should be executable with an old version of Acceleo and existing generators should be executable with the new improvements.

Metamodel Changes

The removal of the CST would remove its metamodel and all its use in the parser and the tooling. The metamodel used by Acceleo modules (AST) would be intact.

API Changes

API removal: CST API change: The API provided by the Acceleo parser would evolve to reflect the removal of the CST API addition: The new API using only the AST

User Interface Changes

none

Documentation Changes

none

Tests and Non-regression strategy

Parse and save an Acceleo module with the current parser and with the new parser and compare the differences.

Implementation choices and tradeoffs