Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Re: CacheAdapter performance issue
Re: CacheAdapter performance issue [message #1015157] Wed, 27 February 2013 15:31 Go to next message
Joel Greenyer is currently offline Joel GreenyerFriend
Messages: 170
Registered: July 2009
Senior Member
Hi Christian,
thanks for your answer and clarifying the purpose of the CacheAdapter.

If I understand you correctly, the solution you propose does not allow me to selectively deactivate the regular CacheAdapter behavior selectively for our simulation/execution code, does it?

I'm looking for a solution that allows the user to do all the usual stuff with editing UML models, diagrams, etc., which obviously requires the regular CacheAdapter behavior. However, when our simulation executes, changes in the our runtime-model should not notify theCacheAdapter.
Also I want to be able to ship our application at some point without people having to mess with their UML installation.

One solution that I can imagine is creating a class which is the superclass of all our runtime model classes and where the CacheAdapter cannot be added...

It would be nice if I could plug-in into UML util to specify which elements the CacheAdapter should not be added to.

Do you see another, easier solution?

Thanks

Joel


On 27.02.2013 14:52, Christian W. Damus wrote:
> Hi, Joel,
>
> If the CacheAdapter didn't track inverse references, a bunch of operations in the UML API would run a lot more slowly than they do now. For example, Element::getAppliedStereotypes() and its cohorts. Consider that such operations would have to walk the resource set to find inverse references, every time.
>
> If your usage is sufficiently constrained and your application well isolated (by classpath) from others, then you can plug in your own implementation of the CacheAdapter to suit your needs. Basically, it amounts to setting the "org.eclipse.uml2.common.util.CacheAdapter.INSTANCE" system property to name your custom implementation; see how the shared CacheAdapter instance is initialized in the createCacheAdapter() method and it will be clear what to do.
>
> HTH,
>
> Christian
>
>
> On 2013-02-27 08:30:02 +0000, Joel Greenyer said:
>
>> Hi,
>> we are building a tool for executing UML models by interpretation.
>> When looking to increase the performance, I found during profiling that there are many time-consuming calls of InverseCrossReferencer.add().
>> They come from the CacheAdapter, which is notified of virtually any operation on our runtime objects.
>> These operations do not change the UML model itself, so I think that whatever the CacheAdapter is doing (unfortunately, I'm not an expert here), it's not necessary.
>>
>> Is there any way to prevent the CacheAdapter from listening to changes?
>>
>> Thanks
>>
>> Joel
>
>
Re: CacheAdapter performance issue [message #1015212 is a reply to message #1015157] Wed, 27 February 2013 18:42 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 831
Registered: July 2009
Senior Member
Hi, Joel,

Please don't e-mail me. Replying to the newsgroup suffices.

More comments below.

cW


On 2013-02-27 15:31:38 +0000, Joel Greenyer said:

> Hi Christian,
> thanks for your answer and clarifying the purpose of the CacheAdapter.
>
> If I understand you correctly, the solution you propose does not allow
> me to selectively deactivate the regular CacheAdapter behavior
> selectively for our simulation/execution code, does it?

Well, your own custom CacheAdapter implementation that you plug in can,
in theory, do anything you need it to. It could be tunable on-the-fly.


> I'm looking for a solution that allows the user to do all the usual
> stuff with editing UML models, diagrams, etc., which obviously requires
> the regular CacheAdapter behavior. However, when our simulation
> executes, changes in the our runtime-model should not notify
> theCacheAdapter.
> Also I want to be able to ship our application at some point without
> people having to mess with their UML installation.

That is, you want the best of all worlds? So do we all. :-)


> One solution that I can imagine is creating a class which is the
> superclass of all our runtime model classes and where the CacheAdapter
> cannot be added...

EMF permits substitution of the globally registered EFactory for UML,
but then your custom UML model implementation would be active globally,
which probably isn't what you want.

But, now it sounds like you're talking about a model that you generated
from UML, with the option to use the CacheAdapter, but your model is
*not* UML. Is that right? In that case, why not just not generate
with the CacheAdapter option?


> It would be nice if I could plug-in into UML util to specify which
> elements the CacheAdapter should not be added to.

That might be something that the UML project would consider, but it
sounds like a "loaded gun" for data integrity and performance issues.
Could be a hard sell.


> Do you see another, easier solution?

Not immediately. How severe is the performance problem? For most use
cases, cutting out the CacheAdapter produces orders of magnitude worse
performance issues ... at least, such is what historical experiments
have shown (years ago, now; the memory is faint).


>
> Thanks
>
> Joel
>
>
> On 27.02.2013 14:52, Christian W. Damus wrote:
>> Hi, Joel,
>>
>> If the CacheAdapter didn't track inverse references, a bunch of
>> operations in the UML API would run a lot more slowly than they do now.
>> For example, Element::getAppliedStereotypes() and its cohorts. Consider
>> that such operations would have to walk the resource set to find
>> inverse references, every time.
>>
>> If your usage is sufficiently constrained and your application well
>> isolated (by classpath) from others, then you can plug in your own
>> implementation of the CacheAdapter to suit your needs. Basically, it
>> amounts to setting the
>> "org.eclipse.uml2.common.util.CacheAdapter.INSTANCE" system property to
>> name your custom implementation; see how the shared CacheAdapter
>> instance is initialized in the createCacheAdapter() method and it will
>> be clear what to do.
>>
>> HTH,
>>
>> Christian
>>
>>
>> On 2013-02-27 08:30:02 +0000, Joel Greenyer said:
>>
>>> Hi,
>>> we are building a tool for executing UML models by interpretation.
>>> When looking to increase the performance, I found during profiling that
>>> there are many time-consuming calls of InverseCrossReferencer.add().
>>> They come from the CacheAdapter, which is notified of virtually any
>>> operation on our runtime objects.
>>> These operations do not change the UML model itself, so I think that
>>> whatever the CacheAdapter is doing (unfortunately, I'm not an expert
>>> here), it's not necessary.
>>>
>>> Is there any way to prevent the CacheAdapter from listening to changes?
>>>
>>> Thanks
>>>
>>> Joel
Re: CacheAdapter performance issue [message #1015247 is a reply to message #1015212] Wed, 27 February 2013 21:16 Go to previous messageGo to next message
Joel Greenyer is currently offline Joel GreenyerFriend
Messages: 170
Registered: July 2009
Senior Member
On 27.02.2013 19:42, Christian W. Damus wrote:
> Hi, Joel,
>
> Please don't e-mail me. Replying to the newsgroup suffices.

sorry, it wasn't intended. I just hit "reply all".

>
> More comments below.
>
> cW
>
>
> On 2013-02-27 15:31:38 +0000, Joel Greenyer said:
>
>> Hi Christian,
>> thanks for your answer and clarifying the purpose of the CacheAdapter.
>>
>> If I understand you correctly, the solution you propose does not allow me to selectively deactivate the regular CacheAdapter behavior selectively for our simulation/execution code, does it?
>
> Well, your own custom CacheAdapter implementation that you plug in can, in theory, do anything you need it to. It could be tunable on-the-fly.
>
>
>> I'm looking for a solution that allows the user to do all the usual stuff with editing UML models, diagrams, etc., which obviously requires the regular CacheAdapter behavior. However, when our simulation executes, changes in the our runtime-model should not notify theCacheAdapter.
>> Also I want to be able to ship our application at some point without people having to mess with their UML installation.
>
> That is, you want the best of all worlds? So do we all. :-)
>
>
>> One solution that I can imagine is creating a class which is the superclass of all our runtime model classes and where the CacheAdapter cannot be added...
>
> EMF permits substitution of the globally registered EFactory for UML, but then your custom UML model implementation would be active globally, which probably isn't what you want.
>
> But, now it sounds like you're talking about a model that you generated from UML, with the option to use the CacheAdapter, but your model is *not* UML. Is that right? In that case, why not just not generate with the CacheAdapter option?

Yes, I'm not modifying UML itself. The model is an EMF model that depends on UML.
In the genmodel(s), the UML2->Cache Adapter Support is set to false, but still the CacheAdapter adds itself to he model elements.
Am I missing something here or is there anything I else can set in the genmodel?

What I tried now is setting the "Root Extends Class" not to EObjectImpl, but to the custom one shown below.

This prohibits the CacheAdapter adding itself, and the performance is increased by ~factor 10!
I'm happy now, but it feels a bit like a hack.



public class RuntimeEObjectImpl extends EObjectImpl {

/*
* Javadoc copied from interface.
*/
@Override
public EList<Adapter> eAdapters()
{
if (eAdapters == null)
{
eAdapters = new RuntimeEAdapterList<Adapter>(this);
}
return eAdapters;
}

public static class RuntimeEAdapterList<E extends Object & Adapter> extends EAdapterList{

public RuntimeEAdapterList(Notifier arg0) {
super(arg0);
// TODO Auto-generated constructor stub
}

@Override
public boolean add(Object object) {
if (object instanceof CacheAdapter)
return false;
return super.add(object);
}

@Override
public void add(int index, Object object) {
if (object instanceof CacheAdapter)
return;
super.add(index, object);
}
}
}



>
>
>> It would be nice if I could plug-in into UML util to specify which elements the CacheAdapter should not be added to.
>
> That might be something that the UML project would consider, but it sounds like a "loaded gun" for data integrity and performance issues. Could be a hard sell.
>
>
>> Do you see another, easier solution?
>
> Not immediately. How severe is the performance problem? For most use cases, cutting out the CacheAdapter produces orders of magnitude worse performance issues ... at least, such is what historical experiments have shown (years ago, now; the memory is faint).
>
>
>>
>> Thanks
>>
>> Joel
>>
>>
>> On 27.02.2013 14:52, Christian W. Damus wrote:
>>> Hi, Joel,
>>>
>>> If the CacheAdapter didn't track inverse references, a bunch of operations in the UML API would run a lot more slowly than they do now. For example, Element::getAppliedStereotypes() and its cohorts. Consider that such operations would have to walk the resource set to find inverse references, every time.
>>>
>>> If your usage is sufficiently constrained and your application well isolated (by classpath) from others, then you can plug in your own implementation of the CacheAdapter to suit your needs. Basically, it amounts to setting the "org.eclipse.uml2.common.util.CacheAdapter.INSTANCE" system property to name your custom implementation; see how the shared CacheAdapter instance is initialized in the createCacheAdapter() method and it will be clear what to do.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> On 2013-02-27 08:30:02 +0000, Joel Greenyer said:
>>>
>>>> Hi,
>>>> we are building a tool for executing UML models by interpretation.
>>>> When looking to increase the performance, I found during profiling that there are many time-consuming calls of InverseCrossReferencer.add().
>>>> They come from the CacheAdapter, which is notified of virtually any operation on our runtime objects.
>>>> These operations do not change the UML model itself, so I think that whatever the CacheAdapter is doing (unfortunately, I'm not an expert here), it's not necessary.
>>>>
>>>> Is there any way to prevent the CacheAdapter from listening to changes?
>>>>
>>>> Thanks
>>>>
>>>> Joel
>
>
Re: CacheAdapter performance issue [message #1015273 is a reply to message #1015247] Thu, 28 February 2013 01:15 Go to previous message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 831
Registered: July 2009
Senior Member
On 2013-02-27 21:16:46 +0000, Joel Greenyer said:

>>
>> But, now it sounds like you're talking about a model that you generated
>> from UML, with the option to use the CacheAdapter, but your model is
>> *not* UML. Is that right? In that case, why not just not generate
>> with the CacheAdapter option?
>
> Yes, I'm not modifying UML itself. The model is an EMF model that
> depends on UML.
> In the genmodel(s), the UML2->Cache Adapter Support is set to false,
> but still the CacheAdapter adds itself to he model elements.
> Am I missing something here or is there anything I else can set in the
> genmodel?

Ah, I see.

The thing is, UML itself was generated with the CacheAdapter option, so
UML causes the CacheAdapter to be attached to the entire reachable
graph of objects. So, your own generated API won't use the
CacheAdapter for caching derived features etc. but UML still does.


> What I tried now is setting the "Root Extends Class" not to
> EObjectImpl, but to the custom one shown below.
>
> This prohibits the CacheAdapter adding itself, and the performance is
> increased by ~factor 10!
> I'm happy now, but it feels a bit like a hack.

Well, maybe it is a hack and maybe it isn't. The UML API, itself,
doesn't need the CacheAdapter to be attached to anything that's not a
UML element or a stereotype application, and you haven't messed with
that.

However, the CacheAdapter is an ECrossReferenceAdapter (which is your
problem!) and any other code that expects it to have a complete picture
of the cross-references to UML elements from other domains (such as
yours) will be unhappy to find holes. But that may not matter in your
case.

Testing will tell whether anything else is broken. I think you'll
probably be fine.

Cheers,

Christian
Previous Topic:CacheAdapter performance issue
Next Topic:Problem loading a UML model with a profile applied
Goto Forum:
  


Current Time: Thu Nov 27 08:42:53 GMT 2014

Powered by FUDForum. Page generated in 0.03133 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software