Eclipse Community Forums: TMF (Xtext) » Limit scope provider to few files

Help

Home

Home » Modeling » TMF (Xtext) » Limit scope provider to few files

Show: Today's Messages :: Show Polls :: Message Navigator

Limit scope provider to few files [message #1745208]

Thu, 06 October 2016 14:28

Anakreontas Mentis

Messages: 85
Registered: October 2014

Member

A file in the DSL I am working on gets variables and function declarations from

Current file
One file implicitly included by all
Files explicitly included with #include

I use this fragment

    		fragment = scoping.ImportURIScopingFragment auto-inject {
    			ignoreCase = true
               }

and provide a descendant of ImportUriGlobalScopeProvider and ImportUriResolver to handle the implicit import and #include statements respectively.

Variables are resolved properly but performance is quite bad. If I go to Project -> Clean, Eclipse runs in the background a long, CPU intensive process (see attached screenshot) and Eclipse becomes sluggish. My understanding is that this process constructs an index of some sort and scope provider is involved.

If I remove the scoping fragment, variables defined in included file fail to resolve, the process of building the index still goes on but for seconds instead of minutes.

I suspect that the index is useful only for namespace based variable resolution. How can I disable the index building processes and keep the scope provider for the file the user is editing?

Regards

Attachment: screen.png
(Size: 14.94KB, Downloaded 84 times)

Report message to a moderator

Re: Limit scope provider to few files [message #1745228 is a reply to message #1745208]

Thu, 06 October 2016 16:36

Christian Dietrich

Messages: 14502
Registered: July 2009

Senior Member

Hi

i doubt your assumtions on building the index is wrong. its not building the index (that would be writing resource descriptions) but it is updating resource descriptions which is resolving cross references and validation.

i assume you use xtext >= 2.9.0. Since the Xtext team decided some years ago import uri based scoping no longer beeing a encouraged way there is no support in the workflows to get this done.

in old <=2.8.4 workflows you usually use

fragment = scoping.ImportURIScopingFragment auto-inject {}
fragment = exporting.SimpleNamesFragment auto-inject {}

which provides the following bindings.

public Class<? extends org.eclipse.xtext.scoping.IGlobalScopeProvider> bindIGlobalScopeProvider() {
return org.eclipse.xtext.scoping.impl.ImportUriGlobalScopeProvider.class;
}

// contributed by org.eclipse.xtext.generator.scoping.AbstractScopingFragment
public void configureIgnoreCaseLinking(com.google.inject.Binder binder) {
binder.bindConstant().annotatedWith(org.eclipse.xtext.scoping.IgnoreCaseLinking.class).to(false);
}

public Class<? extends org.eclipse.xtext.naming.IQualifiedNameProvider> bindIQualifiedNameProvider() {
return org.eclipse.xtext.naming.SimpleNameProvider.class;
}

public void configureIScopeProviderDelegate(com.google.inject.Binder binder) {
binder.bind(org.eclipse.xtext.scoping.IScopeProvider.class).annotatedWith(com.google.inject.name.Names.named(org.eclipse.xtext.scoping.impl.AbstractDeclarativeScopeProvider.NAMED_DELEGATE)).to(org.eclipse.xtext.scoping.impl.SimpleLocalScopeProvider.class);
}

so adding these bindings and a grammar like

Model:
imports+=Import*
....
;
Import:
"#include" importURI=STRING
;

should basically do the behaviour in pre 2.9

https://www.eclipse.org/forums/index.php/m/1736385/?srch=SimpleLocalScopeProvider#msg_1736385

you said that you customized some of the impls and use ignore case linking

if you leave off both (by adding explicit imports for default, use case sensitive linking)
how is the performance then?

besides this: you should always measure what the actual performance bottleneck is and not work on assumptions.

you could even use the default namespace based behaviuor by

(1) give the elements a name like "file.extension.elementname"
(2) turn a include into a import "file.extension.*"

(you gave to few infos how your includes work - eg regarding relative imports/paths etc)

Need professional support for Xtext, Xpand, EMF?
Go to: https://www.itemis.com/en/it-services/methods-and-tools/xtext
Twitter : @chrdietrich
Blog : https://www.dietrich-it.de

Report message to a moderator

Re: Limit scope provider to few files [message #1745242 is a reply to message #1745228]

Thu, 06 October 2016 19:43

Anakreontas Mentis

Messages: 85
Registered: October 2014

Member

Thank you for the detailed answer.

I am using the latest XText. You guessed the syntax for imports correctly.

I removed from mwe the fragment about ImportURIScopingFragment and SimpleNames. However, I have in *RuntimeModule.java the following

	// contributed by org.eclipse.xtext.generator.scoping.AbstractScopingFragment
	@Override
	public Class<? extends org.eclipse.xtext.scoping.IGlobalScopeProvider> bindIGlobalScopeProvider() {
		return P4ImportUriGlobalScopeProvider.class;
	}

	// contributed by org.eclipse.xtext.generator.scoping.AbstractScopingFragment
	public void configureIgnoreCaseLinking(com.google.inject.Binder binder) {
		binder.bindConstant().annotatedWith(org.eclipse.xtext.scoping.IgnoreCaseLinking.class).to(true);
	}

	public Class<? extends ImportUriResolver> bindImportUriResolver() {
		return P4ImportUriResolver.class;
	}

	public Class<? extends IDefaultResourceDescriptionStrategy> bindIDefaultResourceDescriptionStrategy() {
		return P4ResourceDescriptionStrategy.class;
	}

My resource description strategy ignores some resources to minimize the work of index building process.

I did not expect any difference in performance since I am still using my own global scope provider but strangely updating the index went from 95 seconds to 7. As far as I can tell variables are resolved correctly.

I don't know why these modifications improved performance. What tools do you use for monitoring XText plugins? JVM Monitor reports memory usage but nothing about CPU.

Regards

Report message to a moderator