| Summary: | Editing is sluggish | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Henrik Lindberg <henrik.lindberg> | ||||||||
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | CC: | codazzo, jan, sebastian.zarnekow, sven.efftinge, tmf.xtext-inbox | ||||||||
| Version: | 1.0.0 | Flags: | sebastian.zarnekow:
helios+
|
||||||||
| Target Milestone: | SR1 | ||||||||||
| Hardware: | Macintosh | ||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Henrik Lindberg
Is this specific to the Xtext grammar editor or do you face this in other Xtext languages as well? We should profile the mentioned situation. (In reply to comment #1) > Is this specific to the Xtext grammar editor or do you face this in other Xtext > languages as well? Have not seen this when editing with the generated b3 DSL editor - but I have no ".b3" files that are anywhere near as complex as the BeeLang.xtext file, so I am not sure if that is an indication of anything. Related observations (that I could not replicate): - When starting my test "spaces..."/"backspace" sequence while Eclipse was "warming up", I managed to deadlock the IDE - it stopped with "Building the workspace 36%" - I killed the IDE after a couple of minutes. - One time, when editing, Eclipse was not only slow, but blocked - when checking on CPU it was far from saturated. These two made me suspect that something is not quite right with jobs/locking - perhaps spawning too many and not locking as they should... - but it is just a wild guess. (In reply to comment #2) > We should profile the mentioned situation. I think Sebastian keeps a b3 workspace around :) Let me know how I can help. I think profiling the Xtext grammar editor with the b3 grammar, should be sufficient to face this. Created attachment 170359 [details]
Patch: Don't run Xtext2Ecore transformation if there is no generated MM
The profiler showed we're spending a lot of time in Xtext2EcoreTransformer$3.caseGroup(Group) even though there is no generated metamodel in this grammar.
The attached patch skips some expensive steps if there is no generated metamodel. I am not sure whether this is the right place to do that, but the transformer seems to have a bunch of additional tasks, e.g. removing no longer needed metamodels from the reosurce set. Please revise.
Editing is still a bit slow, but given the complexity of the grammar this seems acceptable. I'll investigate a bit more.
The patch skips calls to e.g. checkDatatypeRules() for every ePackage and not only the generated ones. I expect this to be a breaking change. Futhermore there are cross links that will not be established due to the guard condition, e.g. MyRule: ... body .. ; has no concrete syntax for the TypeRef but getOrComputeReturnType will create the instance on demand and thereby set the return type of the rule. Not in Helios Scheduled for SR1 to ensure that we do not miss any room for performance improvements. Created attachment 175726 [details]
Enable caching for XtextLinker
Caching was completely disabled for the XtextLinker since it is an eager linker. The patch enables caching and thereby improves the performance dramatically. Futhermore, a specialized IResourceDescription.Manager is registered, that will create descriptions more efficiently.
Please review the patch. I applied it already in HEAD but if there are any problems, it is safe / easy to roll it back by applying the reverse patch. The editing experience is improved. Closing the outline will improve it further. Patch looks good. Created attachment 175846 [details]
New implementation of DamagerRepairer
The attached patch has been committed to CVS HEAD.
The presentation damager will be configured if you regenerate your language. Previous impl was marked as deprecated and not removed because it exposes API such as public inner classes.
A better name for the FastDamagerRepairer is welcome.
Fixed in HEAD. Closing bug which were set to RESOLVED before Eclipse Neon.0. |