|
Re: Problem with EMFT Compare [message #96828 is a reply to message #96798] |
Mon, 17 September 2007 08:07 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
|
This is a multi-part message in MIME format.
--------------000402060106060003060905
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Hi,
The comparison time is quite dependent of the model's structure. A
"flat" model with all elements at the same hierarchy level will be way
longer to compare than a well structured model.
We have compared models of size exceeding 5MB with EMF Compare before
0.7 went RC; and though it was slow, it didn't fail with those dreaded
"java heap size" exceptions.
In order to be sure of this, I just created two models of 550k and
compared them both with 0.7RC3 and the current CVS version and didn't
notice any exceptions. Comparison time was about 40sec.
My computer has 2GB of RAM. I run EMF Compare under Eclipse Europa 3.3.0
I20070625-1500 with its default memory settings (I think it was -Xmx512m).
Yours could be models provoking bugs in EMF Compare. Are those Ecore or
UML models? Other possible problems could come from the Eclipse you're
using (we havent tested EMF Compare under 3.1). You'd probably want to
check the "default search window" preference for EMF Compare (under
Eclipse : Window => Preferences => EMF Compare) too and lower its value
to see if you get any improvement. If you cannot find the cause and your
models aren't confidential, I'd like to look further into this.
Cheers.
Laurent Goubet
Obeo
MK a
|
|
|
Re: Problem with EMFT Compare [message #609718 is a reply to message #96798] |
Mon, 17 September 2007 08:07 ![Go to previous message Go to previous message](theme/Solstice/images/up.png) |
|
This is a multi-part message in MIME format.
--------------000402060106060003060905
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Hi,
The comparison time is quite dependent of the model's structure. A
"flat" model with all elements at the same hierarchy level will be way
longer to compare than a well structured model.
We have compared models of size exceeding 5MB with EMF Compare before
0.7 went RC; and though it was slow, it didn't fail with those dreaded
"java heap size" exceptions.
In order to be sure of this, I just created two models of 550k and
compared them both with 0.7RC3 and the current CVS version and didn't
notice any exceptions. Comparison time was about 40sec.
My computer has 2GB of RAM. I run EMF Compare under Eclipse Europa 3.3.0
I20070625-1500 with its default memory settings (I think it was -Xmx512m).
Yours could be models provoking bugs in EMF Compare. Are those Ecore or
UML models? Other possible problems could come from the Eclipse you're
using (we havent tested EMF Compare under 3.1). You'd probably want to
check the "default search window" preference for EMF Compare (under
Eclipse : Window => Preferences => EMF Compare) too and lower its value
to see if you get any improvement. If you cannot find the cause and your
models aren't confidential, I'd like to look further into this.
Cheers.
Laurent Goubet
Obeo
MK a
|
|
|
Powered by
FUDForum. Page generated in 0.03745 seconds