| Performance Issues [message #1122460] |
Tue, 01 October 2013 15:48  |
 First Last
Messages: 17
Registered: March 2013 |
Junior Member |
|
|
I have essentially completed a DSL which is intended to generate a number (~50-100) of classes, along with some inner classes, and a few enums, interfaces, annotations, etc...
During initial testing, generating only 5-10 classes, the system worked fairly well, but there appear to be scaling issues (CPU & memory) that will simply prevent it from being usable. The processing path is somewhat less than optimal, but is linear and does not really explain the scaling issues observed.
While the initial plan was to have the DSL contained in a single file, I attempted to break parts of it into multiple files, hoping this would be more workable. However, this seems to introduce unsolvable issues where types have mutual dependencies upon each other -- yet does not seem to actually be any more efficient.
What would you recommend at this point? I could attempt to make the compilation logic a little faster, but nothing about it seems likely to be critical factor.
Are there inherent scaling limitations with Xtext (or Eclipse) that prevent this level of generation?
If there were some way in the generation process to simply omit re-inference of source elements that had not changed, that would seem very useful; but I can't see any approach to making that determination -- or to reuse the prior inference. Does such a mechanism exist?
|
|
|
|
|
| Re: Performance Issues [message #1122786 is a reply to message #1122512] |
Tue, 01 October 2013 23:31  |
First Last
Messages: 17
Registered: March 2013 |
Junior Member |
|
|
I started with Xtext 2.4.1 on Juno, but happened to upgrade at the same time to Xtext 2.4.3 on Kepler. Yes, processing with xbase/jvmmodelinferrer.
I did not attempt to profile it -- I basically know of a major source of slowness, which is that the inferrer passes data to another Eclipse project (or Jar file), which means that I have to pass the data into a different classloader context, leading to a lot of serialization & copying. And that's surely slow. But it was still "fast enough" for processing a handful of classes.
I would think that splitting up into multiple files would work well. I don't entirely understand what the problem is in terms of resolving cross-file linkage.
The short version of what the inferrer does is:
1. Enumerate all visible resources of Package$Literals::ENTITY using getVisibleContainers, getResourceDescriptions, getExportedObjectsByType, EcoreUtil::resolve -- This list is used to make something like 7 types that need to contain information from every "entity" type in any file.
2. Four more classes are always generated -- these might be customized by the DSL -- These will be similar to the ones in step 3.
3. All the "entity" types defined in the DSL file are then generated -- Each on tends to get all its fields & methods, plus 4-5 extra fields, 10-20 extra methods, often 2 inner classes with several fields & methods each.
I get a huge number of errors logged in stage 1, seemingly related to Bug 413826 and the processing of the resources. Yet the processing does work.
Despite all the roundabout passing of data to another classloader context, it does all eventually flow back and get inferred in the normal way.
Nothing special is being done with scoping at this point -- perhaps something needs to be done -- but it is not clear to me what that might be.
|
|
|
|
Powered by
FUDForum. Page generated in 0.04204 seconds
] 
Search
Help
Register
Login
Home
