Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » GMF Performance issue(No lazy loading)
GMF Performance issue [message #722345] Mon, 05 September 2011 13:05 Go to next message
Key Ofeka is currently offline Key OfekaFriend
Messages: 14
Registered: January 2011
Junior Member
Good day,

the main question is: is it possible to not use editing domains and org.eclipse.emf.ecore.util.ECrossReferenceAdapter?

As far as I can see, GMF is designed to work with editing domains. I'm not against the editing domains, but the one used by GMF

org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder which adds itself to all objects of the resource. So if the repository is quite heavy (and is not yet completely loaded) the performance dies since this behaviour causes to load all objects.

Another one issue is the usage of org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves similarly killing the application performance.

The generated ResourceSetModificationListener is another place.

Is it possible to enable lazy loading somehow?

Thank you.
Re: GMF Performance issue [message #722354 is a reply to message #722345] Mon, 05 September 2011 13:31 Go to previous messageGo to next message
Mickael Istria is currently offline Mickael IstriaFriend
Messages: 858
Registered: July 2009
Location: Grenoble, France
Senior Member

AFAIK, there is no way to tweak these internal things of GMF from a
user-side.
However, it is probably worth opening a ticket on the Bugzilla where you
could share the results of your investigation, and maybe propose
patches, to find out ways to improve that in GMF, and integrate them in
latest release.

Regards,

On 05/09/2011 15:05, Key Ofeka wrote:
> Good day,
>
> the main question is: is it possible to not use editing domains and
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter?
>
> As far as I can see, GMF is designed to work with editing domains. I'm
> not against the editing domains, but the one used by GMF
>
> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain
> works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder
> which adds itself to all objects of the resource. So if the repository
> is quite heavy (and is not yet completely loaded) the performance dies
> since this behaviour causes to load all objects.
>
> Another one issue is the usage of
> org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves
> similarly killing the application performance.
>
> The generated ResourceSetModificationListener is another place.
>
> Is it possible to enable lazy loading somehow?
>
> Thank you.
>


--
http://mickaelistria.wordpress.com
http://twitter.com/#!/mickaelistria
http://www.petalslink.com
Abandoned GMF due to Performance issue [message #723321 is a reply to message #722354] Thu, 08 September 2011 09:27 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
Hi,

Just as a warning to others. We used GMF and it saved a lot of time. But
once we were using larger CDO repositories ( 80,000 objects ) even
though only a few hundred might appear in the GMF generated editor the
lack of lazy or selective loading in the GMF core meant we had to
abandon GMF and re-write using GEF. It tooks minutes to initialize! A shame.

Thx.

David


On 05/09/11 14:31, Mickael Istria wrote:
> AFAIK, there is no way to tweak these internal things of GMF from a
> user-side.
> However, it is probably worth opening a ticket on the Bugzilla where you
> could share the results of your investigation, and maybe propose
> patches, to find out ways to improve that in GMF, and integrate them in
> latest release.
>
> Regards,
>
> On 05/09/2011 15:05, Key Ofeka wrote:
>> Good day,
>>
>> the main question is: is it possible to not use editing domains and
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter?
>>
>> As far as I can see, GMF is designed to work with editing domains. I'm
>> not against the editing domains, but the one used by GMF
>>
>> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain
>>
>> works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder
>> which adds itself to all objects of the resource. So if the repository
>> is quite heavy (and is not yet completely loaded) the performance dies
>> since this behaviour causes to load all objects.
>>
>> Another one issue is the usage of
>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves
>> similarly killing the application performance.
>>
>> The generated ResourceSetModificationListener is another place.
>>
>> Is it possible to enable lazy loading somehow?
>>
>> Thank you.
>>
>
>
Re: Abandoned GMF due to Performance issue [message #723322 is a reply to message #723321] Thu, 08 September 2011 09:52 Go to previous messageGo to next message
Mickael Istria is currently offline Mickael IstriaFriend
Messages: 858
Registered: July 2009
Location: Grenoble, France
Senior Member

On 08/09/2011 11:27, David Wynter wrote:
> Hi,
>
> Just as a warning to others. We used GMF and it saved a lot of time. But
> once we were using larger CDO repositories ( 80,000 objects ) even
> though only a few hundred might appear in the GMF generated editor the
> lack of lazy or selective loading in the GMF core meant we had to
> abandon GMF and re-write using GEF. It tooks minutes to initialize! A
> shame.

Did you reported as a bug in the tracker? Did you try to find out the
cause of the issue and suggest an improvement?

Regards,
--
http://mickaelistria.wordpress.com
http://twitter.com/#!/mickaelistria
http://www.petalslink.com
Re: Abandoned GMF due to Performance issue [message #723418 is a reply to message #723321] Thu, 08 September 2011 13:56 Go to previous messageGo to next message
Mariot Chauvin is currently offline Mariot ChauvinFriend
Messages: 174
Registered: July 2009
Senior Member
Hi,

Le 08/09/2011 11:27, David Wynter a écrit :
> Hi,
>
> Just as a warning to others. We used GMF and it saved a lot of time. But
> once we were using larger CDO repositories ( 80,000 objects ) even
> though only a few hundred might appear in the GMF generated editor the
> lack of lazy or selective loading in the GMF core meant we had to
> abandon GMF and re-write using GEF. It tooks minutes to initialize! A
> shame.

Please before blaming a component which saves you hours of work for a
limited price, consider you may be wrong about your technical
assumptions or have a limited knowledge about them.

GMF Runtime was written before CDO was available, and its main focus is
to fill the gap between EMF and GEF.

Integration between CDO and GMF is not an "easy" task, and its neither
the "fault" of GMF, nor CDO. I definitively need to write an article to
explain challenges to take up.

For you first technical point you try to mix EMF transaction mechanism,
and the CDO one, have a look to Dawn to understand the aftermath.

For your second technical point you could easily customize the creation
of the editin domain with GMF Runtime to fit what you need

It's logical that GMF uses a cross referencer by default, when you work
with local files, a cross-referencer enables you to retrieve very
quickly inverse references.

Regards,

Mariot


>
> Thx.
>
> David
>
>
> On 05/09/11 14:31, Mickael Istria wrote:
>> AFAIK, there is no way to tweak these internal things of GMF from a
>> user-side.
>> However, it is probably worth opening a ticket on the Bugzilla where you
>> could share the results of your investigation, and maybe propose
>> patches, to find out ways to improve that in GMF, and integrate them in
>> latest release.
>>
>> Regards,
>>
>> On 05/09/2011 15:05, Key Ofeka wrote:
>>> Good day,
>>>
>>> the main question is: is it possible to not use editing domains and
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter?
>>>
>>> As far as I can see, GMF is designed to work with editing domains. I'm
>>> not against the editing domains, but the one used by GMF
>>>
>>> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain
>>>
>>>
>>> works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder
>>> which adds itself to all objects of the resource. So if the repository
>>> is quite heavy (and is not yet completely loaded) the performance dies
>>> since this behaviour causes to load all objects.
>>>
>>> Another one issue is the usage of
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves
>>> similarly killing the application performance.
>>>
>>> The generated ResourceSetModificationListener is another place.
>>>
>>> Is it possible to enable lazy loading somehow?
>>>
>>> Thank you.
>>>
>>
>>
>


--
Mariot Chauvin @ Obeo

Blog : http://mariot-thoughts.blogspot.com
Twitter :http://twitter.com/mchv
Professional support : http://obeo.fr/pages/maintenance-and-support/
Re: Abandoned GMF due to Performance issue [message #723474 is a reply to message #723418] Thu, 08 September 2011 15:51 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31774
Registered: July 2009
Senior Member
Mariot,

Indeed. The capabilities provided by things like an
ECrossReferenceAdapter and an EContentAdapter can definitely be more
efficiently supported by a CDO repository. Effort needs to be invested
to make this more flexible in GMF so that CDO's advantages are not lost
because of default implementations that behave poorly in terms of
killing the excellent lazy loading behavior of CDO.


On 08/09/2011 6:56 AM, Mariot Chauvin wrote:
> Hi,
>
> Le 08/09/2011 11:27, David Wynter a écrit :
>> Hi,
>>
>> Just as a warning to others. We used GMF and it saved a lot of time. But
>> once we were using larger CDO repositories ( 80,000 objects ) even
>> though only a few hundred might appear in the GMF generated editor the
>> lack of lazy or selective loading in the GMF core meant we had to
>> abandon GMF and re-write using GEF. It tooks minutes to initialize! A
>> shame.
>
> Please before blaming a component which saves you hours of work for a
> limited price, consider you may be wrong about your technical
> assumptions or have a limited knowledge about them.
>
> GMF Runtime was written before CDO was available, and its main focus
> is to fill the gap between EMF and GEF.
>
> Integration between CDO and GMF is not an "easy" task, and its neither
> the "fault" of GMF, nor CDO. I definitively need to write an article
> to explain challenges to take up.
>
> For you first technical point you try to mix EMF transaction
> mechanism, and the CDO one, have a look to Dawn to understand the
> aftermath.
>
> For your second technical point you could easily customize the
> creation of the editin domain with GMF Runtime to fit what you need
>
> It's logical that GMF uses a cross referencer by default, when you
> work with local files, a cross-referencer enables you to retrieve very
> quickly inverse references.
>
> Regards,
>
> Mariot
>
>
>>
>> Thx.
>>
>> David
>>
>>
>> On 05/09/11 14:31, Mickael Istria wrote:
>>> AFAIK, there is no way to tweak these internal things of GMF from a
>>> user-side.
>>> However, it is probably worth opening a ticket on the Bugzilla where
>>> you
>>> could share the results of your investigation, and maybe propose
>>> patches, to find out ways to improve that in GMF, and integrate them in
>>> latest release.
>>>
>>> Regards,
>>>
>>> On 05/09/2011 15:05, Key Ofeka wrote:
>>>> Good day,
>>>>
>>>> the main question is: is it possible to not use editing domains and
>>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter?
>>>>
>>>> As far as I can see, GMF is designed to work with editing domains. I'm
>>>> not against the editing domains, but the one used by GMF
>>>>
>>>> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain
>>>>
>>>>
>>>>
>>>> works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder
>>>> which adds itself to all objects of the resource. So if the repository
>>>> is quite heavy (and is not yet completely loaded) the performance dies
>>>> since this behaviour causes to load all objects.
>>>>
>>>> Another one issue is the usage of
>>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves
>>>> similarly killing the application performance.
>>>>
>>>> The generated ResourceSetModificationListener is another place.
>>>>
>>>> Is it possible to enable lazy loading somehow?
>>>>
>>>> Thank you.
>>>>
>>>
>>>
>>
>
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Abandoned GMF due to Performance issue [message #723583 is a reply to message #723418] Thu, 08 September 2011 20:58 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
We did investigate, the first email in this thread outlines our
findings. It may be it is not as detailed as someone who knows GMF
internals well, but it seems fairly plain to me.

We have partly completed a GEF equivalent to our original GMF component,
we are sorry we were unaware of the limitation of GMF when used with
CDO, but it was not obvious to us, I did not see documentation that
explained it. We were waiting for the Eclipse ESP plugin :)

Thx.

David

On 08/09/11 14:56, Mariot Chauvin wrote:
> Hi,
>
> Le 08/09/2011 11:27, David Wynter a écrit :
>> Hi,
>>
>> Just as a warning to others. We used GMF and it saved a lot of time. But
>> once we were using larger CDO repositories ( 80,000 objects ) even
>> though only a few hundred might appear in the GMF generated editor the
>> lack of lazy or selective loading in the GMF core meant we had to
>> abandon GMF and re-write using GEF. It tooks minutes to initialize! A
>> shame.
>
> Please before blaming a component which saves you hours of work for a
> limited price, consider you may be wrong about your technical
> assumptions or have a limited knowledge about them.
>
> GMF Runtime was written before CDO was available, and its main focus is
> to fill the gap between EMF and GEF.
>
> Integration between CDO and GMF is not an "easy" task, and its neither
> the "fault" of GMF, nor CDO. I definitively need to write an article to
> explain challenges to take up.
>
> For you first technical point you try to mix EMF transaction mechanism,
> and the CDO one, have a look to Dawn to understand the aftermath.
>
> For your second technical point you could easily customize the creation
> of the editin domain with GMF Runtime to fit what you need
>
> It's logical that GMF uses a cross referencer by default, when you work
> with local files, a cross-referencer enables you to retrieve very
> quickly inverse references.
>
> Regards,
>
> Mariot
>
>
>>
>> Thx.
>>
>> David
>>
>>
>> On 05/09/11 14:31, Mickael Istria wrote:
>>> AFAIK, there is no way to tweak these internal things of GMF from a
>>> user-side.
>>> However, it is probably worth opening a ticket on the Bugzilla where you
>>> could share the results of your investigation, and maybe propose
>>> patches, to find out ways to improve that in GMF, and integrate them in
>>> latest release.
>>>
>>> Regards,
>>>
>>> On 05/09/2011 15:05, Key Ofeka wrote:
>>>> Good day,
>>>>
>>>> the main question is: is it possible to not use editing domains and
>>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter?
>>>>
>>>> As far as I can see, GMF is designed to work with editing domains. I'm
>>>> not against the editing domains, but the one used by GMF
>>>>
>>>> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain
>>>>
>>>>
>>>>
>>>> works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder
>>>> which adds itself to all objects of the resource. So if the repository
>>>> is quite heavy (and is not yet completely loaded) the performance dies
>>>> since this behaviour causes to load all objects.
>>>>
>>>> Another one issue is the usage of
>>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves
>>>> similarly killing the application performance.
>>>>
>>>> The generated ResourceSetModificationListener is another place.
>>>>
>>>> Is it possible to enable lazy loading somehow?
>>>>
>>>> Thank you.
>>>>
>>>
>>>
>>
>
>
Re: Abandoned GMF due to Performance issue [message #723723 is a reply to message #723474] Fri, 09 September 2011 09:13 Go to previous messageGo to next message
Mariot Chauvin is currently offline Mariot ChauvinFriend
Messages: 174
Registered: July 2009
Senior Member
Le 08/09/2011 17:51, Ed Merks a écrit :
> Mariot,
>
> Indeed. The capabilities provided by things like an
> ECrossReferenceAdapter and an EContentAdapter can definitely be more
> efficiently supported by a CDO repository. Effort needs to be invested
> to make this more flexible in GMF so that CDO's advantages are not lost
> because of default implementations that behave poorly in terms of
> killing the excellent lazy loading behavior of CDO.

I agree.
My point is that actually this adaptation of GMF Runtime is far more
easily to achieve than the others challenges to integrate GMF with CDO :

- Specialize _GMFEditingDomainFactory_ to override _configure_ method
- Specialize DestroyElmentCommand to override tearDownIncomingReferences




>
>
> On 08/09/2011 6:56 AM, Mariot Chauvin wrote:
>> Hi,
>>
>> Le 08/09/2011 11:27, David Wynter a écrit :
>>> Hi,
>>>
>>> Just as a warning to others. We used GMF and it saved a lot of time. But
>>> once we were using larger CDO repositories ( 80,000 objects ) even
>>> though only a few hundred might appear in the GMF generated editor the
>>> lack of lazy or selective loading in the GMF core meant we had to
>>> abandon GMF and re-write using GEF. It tooks minutes to initialize! A
>>> shame.
>>
>> Please before blaming a component which saves you hours of work for a
>> limited price, consider you may be wrong about your technical
>> assumptions or have a limited knowledge about them.
>>
>> GMF Runtime was written before CDO was available, and its main focus
>> is to fill the gap between EMF and GEF.
>>
>> Integration between CDO and GMF is not an "easy" task, and its neither
>> the "fault" of GMF, nor CDO. I definitively need to write an article
>> to explain challenges to take up.
>>
>> For you first technical point you try to mix EMF transaction
>> mechanism, and the CDO one, have a look to Dawn to understand the
>> aftermath.
>>
>> For your second technical point you could easily customize the
>> creation of the editin domain with GMF Runtime to fit what you need
>>
>> It's logical that GMF uses a cross referencer by default, when you
>> work with local files, a cross-referencer enables you to retrieve very
>> quickly inverse references.
>>
>> Regards,
>>
>> Mariot
>>
>>
>>>
>>> Thx.
>>>
>>> David
>>>
>>>
>>> On 05/09/11 14:31, Mickael Istria wrote:
>>>> AFAIK, there is no way to tweak these internal things of GMF from a
>>>> user-side.
>>>> However, it is probably worth opening a ticket on the Bugzilla where
>>>> you
>>>> could share the results of your investigation, and maybe propose
>>>> patches, to find out ways to improve that in GMF, and integrate them in
>>>> latest release.
>>>>
>>>> Regards,
>>>>
>>>> On 05/09/2011 15:05, Key Ofeka wrote:
>>>>> Good day,
>>>>>
>>>>> the main question is: is it possible to not use editing domains and
>>>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter?
>>>>>
>>>>> As far as I can see, GMF is designed to work with editing domains. I'm
>>>>> not against the editing domains, but the one used by GMF
>>>>>
>>>>> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain
>>>>>
>>>>>
>>>>>
>>>>> works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder
>>>>> which adds itself to all objects of the resource. So if the repository
>>>>> is quite heavy (and is not yet completely loaded) the performance dies
>>>>> since this behaviour causes to load all objects.
>>>>>
>>>>> Another one issue is the usage of
>>>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves
>>>>> similarly killing the application performance.
>>>>>
>>>>> The generated ResourceSetModificationListener is another place.
>>>>>
>>>>> Is it possible to enable lazy loading somehow?
>>>>>
>>>>> Thank you.
>>>>>
>>>>
>>>>
>>>
>>
>>


--
Mariot Chauvin @ Obeo

Blog : http://mariot-thoughts.blogspot.com
Twitter :http://twitter.com/mchv
Professional support : http://obeo.fr/pages/maintenance-and-support/
Re: Abandoned GMF due to Performance issue [message #724484 is a reply to message #723418] Mon, 12 September 2011 12:41 Go to previous messageGo to next message
David Wynter is currently offline David WynterFriend
Messages: 4624
Registered: July 2009
Senior Member
Hi,

I am not denying that GMF saves time, it would have saved several man
weeks of time if it did perform with CDO when using large repositories.
The reason I raised this here, because I did not find it anywhere else,
is that it does not perform and in fact you waste a weeks effort.

We use lots of different Eclipse plugins together, not in isolation, you
discover these things. It is just a fact, not a criticism. Better for
folk who have large repos know beforehand not to use CDO with GMF. In
time it will be optimized and that is great.

Regards,

David

On 08/09/11 14:56, Mariot Chauvin wrote:
> Hi,
>
> Le 08/09/2011 11:27, David Wynter a écrit :
>> Hi,
>>
>> Just as a warning to others. We used GMF and it saved a lot of time. But
>> once we were using larger CDO repositories ( 80,000 objects ) even
>> though only a few hundred might appear in the GMF generated editor the
>> lack of lazy or selective loading in the GMF core meant we had to
>> abandon GMF and re-write using GEF. It tooks minutes to initialize! A
>> shame.
>
> Please before blaming a component which saves you hours of work for a
> limited price, consider you may be wrong about your technical
> assumptions or have a limited knowledge about them.
>
> GMF Runtime was written before CDO was available, and its main focus is
> to fill the gap between EMF and GEF.
>
> Integration between CDO and GMF is not an "easy" task, and its neither
> the "fault" of GMF, nor CDO. I definitively need to write an article to
> explain challenges to take up.
>
> For you first technical point you try to mix EMF transaction mechanism,
> and the CDO one, have a look to Dawn to understand the aftermath.
>
> For your second technical point you could easily customize the creation
> of the editin domain with GMF Runtime to fit what you need
>
> It's logical that GMF uses a cross referencer by default, when you work
> with local files, a cross-referencer enables you to retrieve very
> quickly inverse references.
>
> Regards,
>
> Mariot
>
>
>>
>> Thx.
>>
>> David
>>
>>
>> On 05/09/11 14:31, Mickael Istria wrote:
>>> AFAIK, there is no way to tweak these internal things of GMF from a
>>> user-side.
>>> However, it is probably worth opening a ticket on the Bugzilla where you
>>> could share the results of your investigation, and maybe propose
>>> patches, to find out ways to improve that in GMF, and integrate them in
>>> latest release.
>>>
>>> Regards,
>>>
>>> On 05/09/2011 15:05, Key Ofeka wrote:
>>>> Good day,
>>>>
>>>> the main question is: is it possible to not use editing domains and
>>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter?
>>>>
>>>> As far as I can see, GMF is designed to work with editing domains. I'm
>>>> not against the editing domains, but the one used by GMF
>>>>
>>>> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain
>>>>
>>>>
>>>>
>>>> works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder
>>>> which adds itself to all objects of the resource. So if the repository
>>>> is quite heavy (and is not yet completely loaded) the performance dies
>>>> since this behaviour causes to load all objects.
>>>>
>>>> Another one issue is the usage of
>>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves
>>>> similarly killing the application performance.
>>>>
>>>> The generated ResourceSetModificationListener is another place.
>>>>
>>>> Is it possible to enable lazy loading somehow?
>>>>
>>>> Thank you.
>>>>
>>>
>>>
>>
>
>
Re: Abandoned GMF due to Performance issue [message #724597 is a reply to message #723321] Mon, 12 September 2011 16:01 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6538
Registered: July 2009
Senior Member
Hi,

CDO makes your models scale well because it supports lazy loading and unloading, see
http://thegordian.blogspot.com/2008/11/how-scalable-are-my-models.html . Of course you have more server round trips with
lazy loading which can result in pretty bad user experience when an action triggers demand loading of a vast number of
objects in a short time. To compensate this trade-off to a certain degree CDO offers a number of prefetching strategy
options as well as API for manually prefetching subtrees of objects. This may be especially important in the context of
GMF where the notational instances are being stored in CDO with CDO's legacy model mode (the GMF notation model is not
regenerated for CDO). The reason is that instances of such legacy models are loaded recursively by CDO, in other words
they share the disadvantages of lazy loading but do not profit from the advantages. This way or that way, it seems
likely that prefetching the entire diagram resources makes a huge difference. If you need more details on how to do
this, please let me know.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 08.09.2011 11:27, schrieb David Wynter:
> Hi,
>
> Just as a warning to others. We used GMF and it saved a lot of time. But once we were using larger CDO repositories (
> 80,000 objects ) even though only a few hundred might appear in the GMF generated editor the lack of lazy or selective
> loading in the GMF core meant we had to abandon GMF and re-write using GEF. It tooks minutes to initialize! A shame.
>
> Thx.
>
> David
>
>
> On 05/09/11 14:31, Mickael Istria wrote:
>> AFAIK, there is no way to tweak these internal things of GMF from a
>> user-side.
>> However, it is probably worth opening a ticket on the Bugzilla where you
>> could share the results of your investigation, and maybe propose
>> patches, to find out ways to improve that in GMF, and integrate them in
>> latest release.
>>
>> Regards,
>>
>> On 05/09/2011 15:05, Key Ofeka wrote:
>>> Good day,
>>>
>>> the main question is: is it possible to not use editing domains and
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter?
>>>
>>> As far as I can see, GMF is designed to work with editing domains. I'm
>>> not against the editing domains, but the one used by GMF
>>>
>>> org.eclipse.gmf.runtime.diagram.core.DiagramEditingDomainFactory.DiagramEditingDomain
>>>
>>> works with org.eclipse.emf.transaction.impl.TransactionChangeRecorder
>>> which adds itself to all objects of the resource. So if the repository
>>> is quite heavy (and is not yet completely loaded) the performance dies
>>> since this behaviour causes to load all objects.
>>>
>>> Another one issue is the usage of
>>> org.eclipse.emf.ecore.util.ECrossReferenceAdapter, which behaves
>>> similarly killing the application performance.
>>>
>>> The generated ResourceSetModificationListener is another place.
>>>
>>> Is it possible to enable lazy loading somehow?
>>>
>>> Thank you.
>>>
>>
>>
>


Previous Topic:Path of the current diagram
Next Topic:Changing Appearance of Properties View
Goto Forum:
  


Current Time: Tue Mar 02 15:31:59 GMT 2021

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

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

Back to the top