Home » Modeling » GMF (Graphical Modeling Framework) » GMF Performance issue(No lazy loading)
|
Re: GMF Performance issue [message #722354 is a reply to message #722345] |
Mon, 05 September 2011 13:31 |
|
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 |
David Wynter 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 #723418 is a reply to message #723321] |
Thu, 08 September 2011 13:56 |
Mariot Chauvin 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 |
Ed Merks Messages: 33216 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 |
David Wynter 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 |
Mariot Chauvin 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 |
David Wynter 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 |
|
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.
>>>
>>
>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Sep 20 14:41:05 GMT 2024
Powered by FUDForum. Page generated in 0.05494 seconds
|