Eclipse Community Forums: TMF (Xtext) » Inefficient Validation

Home » Modeling » TMF (Xtext) » Inefficient Validation(@Check Validation is called for entire DSL )

Inefficient Validation [message #1861093]

Wed, 20 September 2023 06:03

Eclipse User

Hello,

I hope somebody can help me... we have huge performance problems because of XText validation. We have written dedicated validators for the various entity types that we have in our DSL.

Now, the scripts can be enormous, say we have 300 entities of a certain type in one DSL script. We debugged and observed that just touching one entity causes the 300 to be validated again (and this 3 times).

So my first question is, is this expected? I would expect only the entity that I'm touching to be checked and not the whole DSL. I cannot believe that XText is that inefficient, we must be doing something wrong. Please help us.

BTW we want the @Check to be @Check(CheckMode.FAST)

Re: Inefficient Validation [message #1861103 is a reply to message #1861093]

Wed, 20 September 2023 12:07

Eclipse User

Hi, are you talking about validation on stop typing in editor, save in editor or during build after save
Both should happen 1 time each

Beside that the question would be what you do in your validation

Re: Inefficient Validation [message #1861106 is a reply to message #1861103]

Thu, 21 September 2023 02:55

Eclipse User

Hallo Christian,
Thanks for the quick reply - it is whenever you stop typing (as the @check is in CheckMode.FAST). What I find irritating is that the ENTIRE script is revalidated even if just one entity is edited (one command out of 300). So it is a huge overhead and not usable.

Can you confirm that this is entire validation always takes place or can we limit it to the edited entity?

FYI: The DSL is for Flight Control Procedures of Space missions. The checks are done from the RCP client to a central webserver (over REST/JSON) that holds the information of the commands. The validation is then entirely done in the xtend.

Re: Inefficient Validation [message #1861108 is a reply to message #1861106]

Thu, 21 September 2023 03:04

Eclipse User

there is no exact just the element was changed calculation.
so you dont edit just an entity.
of course you may hash the entitys content (via node model) and skip the validation in your codebase.
but validating 300 entities still should not be a problem.
thus the question would be what you do in your validation(s)

Re: Inefficient Validation [message #1861232 is a reply to message #1861108]

Sun, 01 October 2023 06:15

Eclipse User

Xtext does not support incremental parsing or downstream processing. To do so manually would require super-aware programmers to avoid extreme fragility resulting from inaccurate dependency observation. This is only realistically possible with an autogenerated incremental tool.

However you might be able to do something for your specific grammar. By comparing the model resulting from an earlier fully processed parse and that resulting from the latest parse, you can see what has changed and prune the outer loop of the validator accordingly. However you will firstly enter into the difficult world of model comparison and need an adequate transitive dependency analysis to ensure that you do not over-prune. For a simple language this could be tractable, for a real language no chance.

As an example of a 'simple' language where dependency analysis fails, just use the Sample Ecore Model Editor and change the name of an EClass in the Properties View. All usages of that name in the Editor View do not change until a refresh is forced by e.g. a fold/unfold; the EMF renderer has no dependency analysis.

Re: Inefficient Validation [message #1861288 is a reply to message #1861232]

Wed, 04 October 2023 02:10

Eclipse User

Hi Ed, this is what we will do, it is only very few element-types (but a lot of elements) in the overall text that need a more complex client-server based validation.
Before we started implementing model compares, we wanted to be sure that Xtext does not do this "incremental parsing/validation" (and we just did not find the right way to use it). Our model is easy enough to go thru so we have a good way forward now.
Thanks for your support, this is much appreciated!

Re: Inefficient Validation [message #1861302 is a reply to message #1861288]

Wed, 04 October 2023 12:44

Eclipse User

The question still is why are 300 validation so expensive

Previous Topic:	Xtext 2.33.0.M1 is out
Next Topic:	Default INT value to 0 not serialized in xmi

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 12 07:49:35 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter