Home » Modeling » TMF (Xtext) » ProposalProvider spins CPU
| ProposalProvider spins CPU [message #483406] |
Tue, 01 September 2009 13:58  |
Eclipse User |
|
|
|
Originally posted by: jon.riecke.aleri.com
I'm attempting to use Xtext for a fairly sizable language.
Unfortunately, I've run into issues with the content-assist feature
spinning the CPU, often taking more than 60 seconds (on a modern
machine: a dual-core AMD laptop about 18 months old).
This problem appears to be related to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=287826
I have eliminated all internal alternatives in my grammar, though, and
still have the issue.
I'm wondering whether others have seen problems with the content-assist
features and have other workarounds.
Some observations:
1. The position where the user asks for content assist matters greatly.
The top level of the grammar is something like
ParseStatementsList:
(vals+=Statement ';')* ;
Statement is itself an alternative, with each one beginning with a
keyword, like
Statement:
'foo' FooStatement |
'barbar' BarbarStatement |
'bazbaz' BazbazStatement ;
If the user asks for content assist in the very first statement of the
editing buffer, it's snappy. Any attempt to invoke it after the first
semicolon results in poor performance.
2. The grammar has a large expression syntax (with addition,
multiplication, functions, ...), accessible from some of the statements.
When I remove that part of the grammar, content assist is much faster.
3. I tried many ways of rewriting that first production, moving the
semicolon around into other productions, trying
ParseStatementsList:
(vals+=Statement ';')+ ;
and even limiting the grammar to two statements, e.g.,
ParseStatementsList:
(vals+=Statement ';') (vals1 += Statement ';') ;
and neither one helped.
4. I ran the Eclipse application in debug mode and paused it when it
started spinning. It appears that, in this case, it traverses the
entire grammar. That's what the stack trace looks like, at any rate.
Should traverse the grammar, but it should stop looking at a production
rule when there's a keyword or terminal at the top of an alternative
(and add that to the list of possible following keywords).
5. I tried following the documentation to create a
"MyDslProposalProvider". All that seems to do is add possible
completions to the list; it doesn't prevent the traversal of the grammar
(and the bad behavior).
Any help would be most appreciated, because the tool is really wonderful.
Thank you,
-Jon Riecke
|
|
|
| Re: ProposalProvider spins CPU [message #483444 is a reply to message #483406] |
Tue, 01 September 2009 15:40  |
 Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Jon,
there is not much that you can do about it as the problematic
implementation is private and cannot be exchanged without much effort.
I'll commit a fix for this performance issue in a few minutes. You may
want to use the Xtext CVS Head, the next nightly build from
https://build.eclipse.org/hudson/job/cbi-tmf-xtext-0.7/ or your could
exchange the implementation of
org.eclipse.xtext.ui.common.editor.contentassist.antlr.Parse rBasedContentAssistContextFactory
with the latest version from head.
Hope that helps,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Jon Riecke schrieb:
> I'm attempting to use Xtext for a fairly sizable language.
> Unfortunately, I've run into issues with the content-assist feature
> spinning the CPU, often taking more than 60 seconds (on a modern
> machine: a dual-core AMD laptop about 18 months old).
>
> This problem appears to be related to
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=287826
>
> I have eliminated all internal alternatives in my grammar, though, and
> still have the issue.
>
> I'm wondering whether others have seen problems with the content-assist
> features and have other workarounds.
>
> Some observations:
>
> 1. The position where the user asks for content assist matters greatly.
> The top level of the grammar is something like
>
> ParseStatementsList:
> (vals+=Statement ';')* ;
>
> Statement is itself an alternative, with each one beginning with a
> keyword, like
>
> Statement:
> 'foo' FooStatement |
> 'barbar' BarbarStatement |
> 'bazbaz' BazbazStatement ;
>
> If the user asks for content assist in the very first statement of the
> editing buffer, it's snappy. Any attempt to invoke it after the first
> semicolon results in poor performance.
>
> 2. The grammar has a large expression syntax (with addition,
> multiplication, functions, ...), accessible from some of the statements.
> When I remove that part of the grammar, content assist is much faster.
>
> 3. I tried many ways of rewriting that first production, moving the
> semicolon around into other productions, trying
>
> ParseStatementsList:
> (vals+=Statement ';')+ ;
>
> and even limiting the grammar to two statements, e.g.,
>
> ParseStatementsList:
> (vals+=Statement ';') (vals1 += Statement ';') ;
>
> and neither one helped.
>
> 4. I ran the Eclipse application in debug mode and paused it when it
> started spinning. It appears that, in this case, it traverses the
> entire grammar. That's what the stack trace looks like, at any rate.
> Should traverse the grammar, but it should stop looking at a production
> rule when there's a keyword or terminal at the top of an alternative
> (and add that to the list of possible following keywords).
>
> 5. I tried following the documentation to create a
> "MyDslProposalProvider". All that seems to do is add possible
> completions to the list; it doesn't prevent the traversal of the grammar
> (and the bad behavior).
>
> Any help would be most appreciated, because the tool is really wonderful.
>
> Thank you,
> -Jon Riecke
|
|
|
| Re: ProposalProvider spins CPU [message #483613 is a reply to message #483444] |
Wed, 02 September 2009 10:39 |
| Eclipse User |
|
|
|
Originally posted by: jon.riecke.aleri.com
Works great here too. Thanks!
-Jon
Sebastian Zarnekow wrote:
> Hi Jon,
>
> there is not much that you can do about it as the problematic
> implementation is private and cannot be exchanged without much effort.
>
> I'll commit a fix for this performance issue in a few minutes. You may
> want to use the Xtext CVS Head, the next nightly build from
> https://build.eclipse.org/hudson/job/cbi-tmf-xtext-0.7/ or your could
> exchange the implementation of
> org.eclipse.xtext.ui.common.editor.contentassist.antlr.Parse rBasedContentAssistContextFactory
>
> with the latest version from head.
>
> Hope that helps,
> Sebastian
|
|
|
Goto Forum:
Current Time: Thu Apr 25 16:10:25 GMT 2024
Powered by FUDForum. Page generated in 0.22978 seconds |
] 
Search
Help
Register
Login
Home
