Eclipse Community Forums: UML2 » ExportAllDiagrams/Model Validation very slow on Luna

Help

Home

Home » Modeling » UML2 » ExportAllDiagrams/Model Validation very slow on Luna

Show: Today's Messages :: Show Polls :: Message Navigator

ExportAllDiagrams/Model Validation very slow on Luna [message #1404157]

Wed, 30 July 2014 06:13

Ba sti

Messages: 18
Registered: February 2013

Junior Member

Hi,

I have a problem with migrating from Kepler to Luna. I don´t know if this is the right forum for this.
I have a big uml model that i want to validate using the model validation and i want to export all diagrams to image files using the ExportAllDiagrams functionality, but i figured out, that the validation is very very slow ( over 1 hour compared to 5min in kepler) and the export does nothing ( i canceled the operation after 1,5h with still 0% progress compared to 15min in kepler)..
On small uml models both operations work quite well.

What´s the difference in loading the models between Luna and Kepler?
Is there something i can do to speed up these operations?

Best regards

Report message to a moderator

Re: ExportAllDiagrams/Model Validation very slow on Luna [message #1404165 is a reply to message #1404157]

Wed, 30 July 2014 07:31

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

One possibility:

Luna introduces UML 2.5 support for which the OCL embedded in the UML
model has been tool checked eliminating many hundreds of syntax errors
from UML 2.0 ... UML 2.4.1. As a result the OCL in the UML can be used
for validation. During development I found that it was invoked from the
OCL Validity View. This revealed a couple of functional errors that are
fixed in Eclipse UML 5.0.0. This direct execution was not intended and
so I think I disabled it, but perhaps not until Eclipse OCL 5.0.1, which
has other important fixes for UML/Papyrus users.

See https://wiki.eclipse.org/OCL/New_and_Noteworthy/Luna#SR1

So, try installing Eclipse OCL 5.0.1 and see if it makes any difference.
Please report back if it does.

(In due course the OCL to Java code generator may be used so that all
the embedded OCL constraints are executed without selective manual
transcription to Java and without significant speed penalties.)

Another possibility:

Have a look at the "[EMF] long loading time" thread on the EMF newsgroup
where it seems that inappropriate xmi:id handling can cause O(N*N) effects.

Regards

Ed Willink

On 30/07/2014 07:13, Ba sti wrote:
> Hi,
>
> I have a problem with migrating from Kepler to Luna. I don´t know if
> this is the right forum for this.
> I have a big uml model that i want to validate using the model
> validation and i want to export all diagrams to image files using the
> ExportAllDiagrams functionality, but i figured out, that the
> validation is very very slow ( over 1 hour compared to 5min in kepler)
> and the export does nothing ( i canceled the operation after 1,5h with
> still 0% progress compared to 15min in kepler)..
> On small uml models both operations work quite well.
>
> What´s the difference in loading the models between Luna and Kepler?
> Is there something i can do to speed up these operations?
>
> Best regards

Report message to a moderator

Re: ExportAllDiagrams/Model Validation very slow on Luna [message #1404179 is a reply to message #1404165]

Wed, 30 July 2014 09:19

Ba sti

Messages: 18
Registered: February 2013

Junior Member

hi Ed,

thanks for your answer.
I tried the validation with OCL 5.0.1, but there is no difference in the behavior.

The EMF thread is interesting because there are a lot of ids in my model and n*n would explain this long runtime, but i´m not loading it in standalone so i guess the UMLResourceFactory is used to create the resource?
I looked up the code of this Factory and the option "XMLResource.OPTION_DEFER_IDREF_RESOLUTION" that was mentioned in the other thread is set there, only the second part (setIntrinsicIDToEObjectMap) of the solution from the other thread is missing there but it looks like the same code as it is in Kepler.

I think i have to know what´s going on during runtime to figure out the problem.
Can i somehow debug the validation/export?

Regards,

Report message to a moderator

Re: ExportAllDiagrams/Model Validation very slow on Luna [message #1404198 is a reply to message #1404179]

Wed, 30 July 2014 11:03

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Since most Eclipse projects provide a SDK you can load their plugins
into your workspace with sources and then run them all in a nested
Eclipse using a debug launch. I frequently have a copy of o.e.emf.core
to add some instrumentation. Now that GIT is prevalent, you may prefer
to import from GIT instead. Some projects now have an Oomph installer
that can make setup easier for complex projects such as Papyrus. EMF and
UML are pretty much pure Java so installing projects is easy; just close
projects with errors because they are probably obsolete.

You can also run your Eclipse with
"-Xrunjdwp:server=y,transport=dt_socket,address=14143,suspend=n" on the
startup 'command' so that you can then use another Eclipse to debug a
remote connection on port 14143. This allows direct access to your code,
but you have to keep configuring source attachment paths.

I recommend the GIT approach so that you can add println diagnostics
with timing to the code and maintain your additional code in a branch
that you can reuse later if necessary.

Regards

Ed Willink

On 30/07/2014 10:19, Ba sti wrote:
> hi Ed,
>
> thanks for your answer.
> I tried the validation with OCL 5.0.1, but there is no difference in
> the behavior.
>
> The EMF thread is interesting because there are a lot of ids in my
> model and n*n would explain this long runtime, but i´m not loading it
> in standalone so i guess the UMLResourceFactory is used to create the
> resource?
> I looked up the code of this Factory and the option
> "XMLResource.OPTION_DEFER_IDREF_RESOLUTION" that was mentioned in the
> other thread is set there, only the second part
> (setIntrinsicIDToEObjectMap) of the solution from the other thread is
> missing there but it looks like the same code as it is in Kepler.
>
> I think i have to know what´s going on during runtime to figure out
> the problem.
> Can i somehow debug the validation/export?
>
> Regards,

Report message to a moderator

Re: ExportAllDiagrams/Model Validation very slow on Luna [message #1409903 is a reply to message #1404198]

Tue, 19 August 2014 09:06

Ba sti

Messages: 18
Registered: February 2013

Junior Member

Hi,

I have debugged these operations and regarding to the model validation, there is nothing special i have noticed.
For the whole time, it is doing the normal stuff for valdidating models, so i have still no idea why it is so much slower compared to Kepler.

The ExportAllDiagrams operation makes a call on EcoreUtil.resolveAll and even after hours there is no return from this method.
But these things only occure on the big model.

any ideas?

regards,

Report message to a moderator

Re: ExportAllDiagrams/Model Validation very slow on Luna [message #1409931 is a reply to message #1409903]

Tue, 19 August 2014 10:31

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

Check your VM settings, particularly PermGen.

When I run up Visual VM, I have been surprised at how much memory is
being used and of course that can have really bad consequences.

Use Wireshark to see if any Internet traffic is occuring. Sometimes an
unregistered model causes an Internet timeout to occur. e.g
https://bugs.eclipse.org/bugs/show_bug.cgi?id=364797. Maybe a newer UML
or OCL URI is at fault.

Beyond that start instrumenting e.g. with EcoreUtil.resolveAll println's
with times.

And please report back/raise a Bugzilla.

Regards

Ed Willink

On 19/08/2014 10:06, Ba sti wrote:
> Hi,
>
> I have debugged these operations and regarding to the model validation,
> there is nothing special i have noticed.
> For the whole time, it is doing the normal stuff for valdidating models,
> so i have still no idea why it is so much slower compared to Kepler.
>
> The ExportAllDiagrams operation makes a call on EcoreUtil.resolveAll and
> even after hours there is no return from this method.
> But these things only occure on the big model.
>
> any ideas?
>
> regards,

Report message to a moderator

Previous Topic:	Problems with profile "file:" URI in UML Model Editor
Next Topic:	exception when creating genmodel (Juno)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 11:45:50 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter