Home » Modeling » TMF (Xtext) » Batch type resolution performance problem
| Batch type resolution performance problem [message #1433796] |
Mon, 29 September 2014 08:50  |
 Esa Ryhänen
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
I have a DSL based on Xbase 2.7.0. The problem I'm facing is concerned with type resolution of inferred types across resources.
Resolving the types of a resource will cause the transitive type resolution of all referenced resources, which in our case is very time consuming. In one of our DSL programs opening our "main" DSL resource in Eclipse will trigger type resolution of more than 300 other resources, taking more than 30 seconds to finish.
My problem can actually be illustrated in Xtend, which has the same behaviour as our DSL.
class A {
val b = new B
val fieldA = b.fieldB // Need to resolve type of B#fieldB
}
class B {
public val fieldB = 1
val c = new C
val x = c.fieldC // Will trigger type resolution of class C
}
class C {
public val fieldC = 1
}
Opening class A will trigger batch type resolution. To resolve the type of A#fieldA, the type of B#fieldB need to be resolved. This will trigger batch type resolution of class B. Because batch type resolution will resolve all the types in a resource, the type of B#x will be resolved even though that is not needed in this example. The type resolution of B#x will in turn trigger batch type resolution of class C - We have transitive type resolution.
If the type of B#fieldB could be inferred 'lazily', instead of resolving all the types in B, then we would not get the transitive type resolution. So, my question is:
What would be the proper way, if any, to implement "lazy" type resolution of inferred types across resources?
Thanks
Esa
|
|
|
| Re: Batch type resolution performance problem [message #1433871 is a reply to message #1433796] |
Mon, 29 September 2014 10:52  |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Am 29.09.14 10:50, schrieb Esa Ryhänen:
> I have a DSL based on Xbase 2.7.0. The problem I'm facing is concerned
> with type resolution of inferred types across resources.
>
> Resolving the types of a resource will cause the transitive type
> resolution of all referenced resources, which in our case is very time
> consuming. In one of our DSL programs opening our "main" DSL resource in
> Eclipse will trigger type resolution of more than 300 other resources,
> taking more than 30 seconds to finish.
>
> My problem can actually be illustrated in Xtend, which has the same
> behaviour as our DSL.
>
> class A { val b = new B val fieldA = b.fieldB // Need to resolve type
> of B#fieldB
> }
> class B {
> public val fieldB = 1
> val c = new C
> val x = c.fieldC // Will trigger type resolution of class C
> }
> class C {
> public val fieldC = 1
> }
>
>
> Opening class A will trigger batch type resolution. To resolve the type
> of A#fieldA, the type of B#fieldB need to be resolved. This will trigger
> batch type resolution of class B. Because batch type resolution will
> resolve all the types in a resource, the type of B#x will be resolved
> even though that is not needed in this example. The type resolution of
> B#x will in turn trigger batch type resolution of class C - We have
> transitive type resolution.
>
> If the type of B#fieldB could be inferred 'lazily', instead of
> resolving all the types in B, then we would not get the transitive type
> resolution. So, my question is:
>
> What would be the proper way, if any, to implement "lazy" type
> resolution of inferred types across resources?
>
> Thanks
> Esa
>
Hi Esa,
sorry to hear that you face performance problems.
Type resolution in generally split into a prepare and a compute phase.
If prepare has been done correctly, all signatures contain valid but
potentially lazy type references afterwards. That would be sufficient to
return from the computation. It would be worth a try to split the
computation that that point for non-primary resources.
Best,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
| Re: Batch type resolution performance problem [message #1433910 is a reply to message #1433871] |
Mon, 29 September 2014 11:52 |
Esa Ryhänen
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Hi Sebastian,
and thanks for your answer.
Quote:Type resolution in generally split into a prepare and a compute phase.
If prepare has been done correctly, all signatures contain valid but
potentially lazy type references afterwards. That would be sufficient to
return from the computation.
Just to make clear that I understand you. When you refer to the prepare and compute phase are you talking about LogicalContainerAwareReentrantTypeResolver#computeTypes(ResolvedTypes resolvedTypes, IFeatureScopeSession session)?
If so, only doing the 'prepare' step and not the 'compute' step would make type resolution lazy?
Basically like this:
@Override
protected void computeTypes(ResolvedTypes resolvedTypes, IFeatureScopeSession session) {
EObject root = getRoot();
if (root instanceof JvmType) {
Map<JvmIdentifiableElement, ResolvedTypes> preparedResolvedTypes = prepare(resolvedTypes, session);
//computeTypes(preparedResolvedTypes, resolvedTypes, session, root);
} else {
super.computeTypes(resolvedTypes, session);
}
}
Quote:It would be worth a try to split the
computation that that point for non-primary resources.
How can I distinguish between a primary and a non-primary resource?
Thanks
Esa
|
|
|
| Re: Batch type resolution performance problem [message #1433916 is a reply to message #1433910] |
Mon, 29 September 2014 12:02 |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Hi Esa,
please find my answer inline.
Am 29.09.14 13:52, schrieb Esa Ryhänen:
> Hi Sebastian,
>
> and thanks for your answer.
>
> Quote:
>> Type resolution in generally split into a prepare and a compute phase.
>> If prepare has been done correctly, all signatures contain valid but
>> potentially lazy type references afterwards. That would be sufficient
>> to return from the computation.
>
>
> Just to make clear that I understand you. When you refer to the prepare
> and compute phase are you talking about
> LogicalContainerAwareReentrantTypeResolver#computeTypes(ResolvedTypes
> resolvedTypes, IFeatureScopeSession session)?
>
> If so, only doing the 'prepare' step and not the 'compute' step would
> make type resolution lazy?
> Basically like this:
>
> @Override
> protected void computeTypes(ResolvedTypes resolvedTypes,
> IFeatureScopeSession session) {
> EObject root = getRoot();
> if (root instanceof JvmType) {
> Map<JvmIdentifiableElement, ResolvedTypes>
> preparedResolvedTypes = prepare(resolvedTypes, session);
> //computeTypes(preparedResolvedTypes, resolvedTypes,
> session, root);
> } else {
> super.computeTypes(resolvedTypes, session);
> }
> }
Exactly that would be the starting point. I'd assume there'll be quite a
few hick-ups but generally speaking this would be the way to go. As soon
as I have the time, I'll likely introduce a PreparableTypeTypeResolver
that allows to work with that in a more direct and straight forward way.
>
> Quote:
>> It would be worth a try to split the computation that that point for
>> non-primary resources.
The primary resource is the first in the ResourceSet in the editor. In
the builder context, it may be slightly more involving. #resolveAll
should still trigger the complete resolution whereas all transitively
requested types would be save to use a lazy approach.
Regards,
Sebastian
--
Looking for professional support for Xtext, Xtend or Eclipse Modeling?
Go visit: http://xtext.itemis.com
>
>
> How can I distinguish between a primary and a non-primary resource?
>
> Thanks
> Esa
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:21:16 GMT 2024
Powered by FUDForum. Page generated in 0.03327 seconds |
] 
Search
Help
Register
Login
Home
