Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 314935 - Slow parsing of big elements (using backtracking)
Summary: Slow parsing of big elements (using backtracking)
Status: CLOSED WORKSFORME
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 1.0.0   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: SR1   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-28 14:36 EDT by Sven Efftinge CLA
Modified: 2017-09-19 16:26 EDT (History)
2 users (show)

See Also:
sebastian.zarnekow: helios+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Efftinge CLA 2010-05-28 14:36:22 EDT
Hi,

We have been using XText for some time now, and we are very pleased with the results we have. However, in some extreme cases, we have some performances issues. I created a small example that shows this. The grammar is the following one:

*******
grammar org.xtext.example.MyDsl with org.eclipse.xtext.common.Terminals

generate myDsl "http://www.xtext.org/example/MyDsl"

ADT:
     ("Operations" (operations+=Operation ";")+)?
     ("Axioms" (axioms+=Equation ";")+)?
     ("Variables" (variables+=Variable ";")+)?
;

Operation:
    name = ID
;

Equation:
  left=Term '=' right=Term
;

Term:
    InfixTerm | TerminalTerm
;

TerminalTerm returns Term:
    VariableRef | PrefixTerm | '(' Term ')'
;
    
VariableRef:
    "$" variable = [Variable]
;

PrefixTerm:
    opSymbol=[Operation] ("(" subTerms+=Term ("," subTerms+=Term)* ")")?
;

InfixTerm:
    subTerms+=TerminalTerm opSymbol=[Operation] subTerms+=TerminalTerm
;

Variable:
    name=ID
;
*******

The problem appears when we try to create big terms in the instances, like the following one (integers defined in a Peano-like form):

***
Operations
    zero;
    next;
    plus;
Axioms
    zero plus $n = $n;
    next($n) plus $m = next ($n plus $m);
    next(next(next(next(next(next(next(next(next(next(next(next(next(next(next(next(next(next(next(next(zero)))))))))))))))))))) = zero;
Variables
    n;
    m;
***

Parsing a term with 20 levels takes about 800Mb of in the heap space, which seems a lot of memory (it's really a heap space problem, not a stack size problem).

I have enabled backtracking for this to work, and I absolutely need backtracking in my grammar anyway. Getting rid of infix terms solves the performances problem, but infix terms are a nice feature we'd like to keep.

Is there a way to reduce this memory consumption? Maybe a different definition for my grammar?

Any help will be appreciated :)

Cheers,

Alexis
Comment 1 Sebastian Zarnekow CLA 2010-07-26 10:10:48 EDT
Please try to enable memoization:

options = {
	backtrack = backtracking
	memoize = backtracking
}
Comment 2 Sebastian Zarnekow CLA 2010-07-26 10:19:05 EDT
The snippet should actually read

options = {
  backtrack = true
  memoize = true
}
Comment 3 Alexis Marechal CLA 2010-08-27 17:48:16 EDT
Confirmed, this works great. Thanks a lot!
Comment 4 Karsten Thoms CLA 2017-09-19 16:26:02 EDT
Closing bug which were set to RESOLVED before Eclipse Neon.0.