| [TCS] Performance of TCSRuntime.RefSetting [message #7421] |
Wed, 26 March 2008 08:23  |
Eclipse User |
|
|
|
Hi,
just an idea:
In TCSRuntim.RefSetting, you resolve references by calling
getElementsByType(valueTypeName)
and then searching in the result set for a suitable modelElement.
So instead of doing so, you could change getElementsByType to
setReference(...), and let the ModelAdapter subclass resolve the reference
by itself, allowing implementations of ModelAdapter to improve performance.
|
|
|
| Re: [TCS] Performance of TCSRuntime.RefSetting [message #7442 is a reply to message #7421] |
Thu, 27 March 2008 05:14  |
| Eclipse User |
|
|
|
Hi,
> just an idea:
> In TCSRuntim.RefSetting, you resolve references by calling
> getElementsByType(valueTypeName)
> and then searching in the result set for a suitable modelElement.
>
> So instead of doing so, you could change getElementsByType to
> setReference(...), and let the ModelAdapter subclass resolve the
> reference by itself, allowing implementations of ModelAdapter to improve
> performance.
You are right that performance can be improved. I noticed this recently
when working on relatively large models (in term of number of
references!). Do not hesitate to create a bugzilla entry to follow
resolution of this issue.
My initial idea was to add some kind of cache to the contexts: the first
traversal is complete and populates a Map; subsequent traversals use
this Map.
It seems to me that "textual" reference resolving is a TCS issue (i.e.,
belonging in TCSRuntime), not a ModelAdapter issue. However, I have not
thought it through yet.
Do you have some suggestions regarding the choice between both alternatives?
Regards,
Frédéric Jouault
|
|
|
| Re: [TCS] Performance of TCSRuntime.RefSetting [message #7464 is a reply to message #7442] |
Thu, 27 March 2008 07:37 |
| Eclipse User |
|
|
|
Frédéric Jouault wrote:
> It seems to me that "textual" reference resolving is a TCS issue (i.e.,
> belonging in TCSRuntime), not a ModelAdapter issue. However, I have not
> thought it through yet.
In our context, it is possible that in the DSL, we reference objects in a
model outside the given DSL sample. I.e. as in Java classes you can
reference other classes.
In that case, the TCS Runtime cannot resolve these references anyway.
By calling getType on the ModelAdapter, one may of course also get other
Modelelments not contained in the DSL Sample, but as I said this may be
performance effort that could be avoided in some cases.
I.e. when you want to set a Reference to an instance of Type X with "id" =
123, then the ModelAdapter might just have an index structure on id that
lets him find the right instance in a snap, while the TCS Runtime might
have to iterate over a million instances to find the right one.
For me, the task of DSLRuntime is only to find out that such a reference
needs setting, but it's the ModelAdapters task to find the right
referenced object in the model space.
|
|
|
| Re: [TCS] Performance of TCSRuntime.RefSetting [message #7475 is a reply to message #7464] |
Thu, 27 March 2008 07:53 |
| Eclipse User |
|
|
|
Hi Thibault,
>> It seems to me that "textual" reference resolving is a TCS issue
>> (i.e., belonging in TCSRuntime), not a ModelAdapter issue. However, I
>> have not thought it through yet.
>
> In our context, it is possible that in the DSL, we reference objects in
> a model outside the given DSL sample. I.e. as in Java classes you can
> reference other classes.
> In that case, the TCS Runtime cannot resolve these references anyway.
> By calling getType on the ModelAdapter, one may of course also get other
> Modelelments not contained in the DSL Sample, but as I said this may be
> performance effort that could be avoided in some cases.
>
> I.e. when you want to set a Reference to an instance of Type X with "id"
> = 123, then the ModelAdapter might just have an index structure on id
> that lets him find the right instance in a snap, while the TCS Runtime
> might have to iterate over a million instances to find the right one.
>
> For me, the task of DSLRuntime is only to find out that such a reference
> needs setting, but it's the ModelAdapters task to find the right
> referenced object in the model space.
Indeed, a given DSL may already have an identifier resolver.
Here are some requirements for TCS:
- TCS must work when there is no identifier resolver in a DSL.
- TCS must be able to redefine a (possibly different) identifier
resolver for a DSL with a built-in identifier resolver.
These requirements are already met.
If I understand your suggestion correctly, it is about adding the
following requirement:
- TCS must be able to use an existing identifier resolver.
This seems quite relevant!
Could you please add an "enhancement" bugzilla entry for this?
My current idea regarding the way to implement this is the following:
interface ModelAdapter
// => add a "resolveReference" method
abstract class ModelAdapterWithTCSSpecificReferenceResolver
// => implement resolveReference only
// => we may want to find a simpler name for this class ;-)
class ASMModelAdapter
// extends ModelAdpaterWithTCSSpecificReferenceResolver
This way, it should be relatively easy to define a ModelAdapter reusing
a build-in identifier resolver. It would also be as easy to define a
ModelAdapter using the default TCS identifier resolver.
Regards,
Frédéric Jouault
|
|
|
Powered by
FUDForum. Page generated in 0.04543 seconds
Home