| Summary: | Slow WorkflowRunner for workflows/templates using the JavaBeansMetaModel | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMFT | Reporter: | germund <germund> | ||||
| Component: | MWE | Assignee: | Project Inbox <emft-mwe-inbox> | ||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | sven.efftinge | ||||
| Version: | 0.7 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
It seems that class loading in equinox is more expensive than in a standard Java environment. The problem could be reduced by introducing proxy types, that is currently all types and referenced types are loaded and adapted to Xpand types up front. As you can imagine this can become a quite huge dependency graph. So this is what takes the time when starting the process for the first time. We should introduce type proxies which get resolved lazily (after Galileo). As a workaround you could try to load / initialize the type system once in the background (e.g. when the bundle is activated). Reusing the type system should be ok, as your using a fixed environment. I'm still not sure why the subsequent invocations are slower. I've removed one hot spot but this gained only little improvements. *** This bug has been marked as a duplicate of bug 278753 *** |
Created attachment 137642 [details] Sample Xtext project(s) and one run-time project Build ID: I20090430-2300 Steps To Reproduce: I've attached a small example that reads an ecore model and lists its contained EClasses and their features in a file output.txt. Two sets of workflows and templates are provided for both the EMFRegistryMetaModel and the JavaBeansMetaModel. The UI plug-in declares two popup-menu extensions "Run MyDSL Generator" and "Run MyDSL Generator (JavaBeans)" respectively. You can see how the WorkFlowRunner is called in the classes MyDslGeneratorContextAction.java and MyDslGeneratorContextActionJavaBeans.java. 1. Import the three attached projects org.xtext.example.mydsl... 2. Start a run-time workbench and import the project SlowWorkflowRunnerForJavaBeansMetamodel 3. The src folder contains an ecore model workshop.ecore. Execute the two aforementioned context actions on it. Notice the difference in execution times, especially for the first time running the "Run MyDSL Generator (JavaBeans)" action, but also for consecutive runs. Our actual templates and extensions have initial execution times of several minutes. More information: We are using the WorkflowRunner class to programmatically launch workflows via context actions on files in the workbench. A set of .xpt templates and .ext files are written over the JavaBeansMetaModel so they can be used both for Xtext fragments and otherwise. The generation process takes a considerable amount of time (minutes). What takes time seems to be when the classloader locates the metamodel types (the ecore ones and those of our own grammar metamodels). When the workflow and templates are rewritten over the EMFRegistryMetaModel the workflows complete within milliseconds. There is no difference in execution time when run as mwe workflows in the development workbench. The significant longer execution times arise when run via context actions in the run-time workbench (that programmatically use the WorkflowRunner class).