Community
Participate
Working Groups
When editing the b3 grammar the performance in the editor is really slow. By executing the sequence below, the problem appears for me: With a fresh started Eclipse on a workspace where no editors are open, wait until everything is initialized. Open BeeLang.xtext Insert spaces in a comment (20-30 or so), then erase them with backspace. Repeat This makes CPU go up to near 100% and editing is sluggish. Sometimes an "Xtext validation" is flashing as indication it is running in the background. If I keep repeating this, my mac heats up and the fan kicks in :) By waiting until the fan is again running at slow speed, the editing speed is back to "normal". I have 1.5 Gb memory free in the OS, and a 1Gb heap space for my Eclipse IDE VM. On xtext 1.0 nightly from 2010 05 17 (antlr from 05 18).
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.
