Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » CacheAdapter performance issue
CacheAdapter performance issue [message #1015021] Wed, 27 February 2013 08:30 Go to next message
Joel Greenyer is currently offline Joel GreenyerFriend
Messages: 170
Registered: July 2009
Senior Member
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 #1015114 is a reply to message #1015021] Wed, 27 February 2013 13:52 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
Senior Member

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 #1015130 is a reply to message #1015021] Wed, 27 February 2013 14:33 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

UML is a very powerful modeling notation and since the UML specification
specifies many relationship using subsetting and derived unions, the
MDT/UML2 implementation faithfully supports these using CacheAdapter to
try to improve behaviour significantly for the typically sparse usage of
real models.

Conversely EMOF/Ecore is optimized for run-time representation with no
duplication or representation of analysis subtleties.

If you are looking at efficient execution on top of UML, you might want
to look at the new OCL Pivot-model that is a hybrid of the above design
points. The Pivot model is UML-aligned but has no duplicate
relationships and makes all unnavigable oppisities as navigable, and
reifies stereotypes.

Regards

Ed Willink




On 27/02/2013 08:30, Joel Greenyer wrote:
> 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 #1015156 is a reply to message #1015114] Wed, 27 February 2013 15:31 Go to previous messageGo 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 #1015211 is a reply to message #1015156] Wed, 27 February 2013 18:42 Go to previous messageGo to next message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
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 #1015246 is a reply to message #1015211] 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 #1015272 is a reply to message #1015246] Thu, 28 February 2013 01:15 Go to previous message
Christian Damus is currently offline Christian DamusFriend
Messages: 1270
Registered: July 2009
Location: Canada
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:Store EMF Objects in PreferenceStore
Next Topic:Problem with ExtendedMetaData
Goto Forum:
  


Current Time: Tue Mar 19 09:42:22 GMT 2024

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

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

Back to the top