Eclipse Community Forums: EMF » [Validation] Deterioration of performance with Eclipse Galileo due to Tracing

Home » Modeling » EMF » [Validation] Deterioration of performance with Eclipse Galileo due to Tracing

[Validation] Deterioration of performance with Eclipse Galileo due to Tracing [message #431689]

Tue, 21 July 2009 12:10

Eclipse User

Hi!

I've currently moved from eclipse 3.4 to eclipse 3.5 and I'm
experiencing a huge performance penalty when using (live) validation.

Especially when doing lots of modifications in one single EMF
transaction, the live validation that is performed afterwards takes
about 99% of the entire operation runtime.

Operation runtime:
+ eclipse 3.4: about 10 seconds
+ eclipse 3.5: about 300 seconds

Performance analysis show that almost all runtime is spent on testing if
debugging is enabled (Tracing.shouldTrace invokes Plugin.isDebugging()).

While in eclipse 3.4, Plugin.isDebugging() just returned a boolean field
value, in eclipse 3.5 the debug options are queried which causes
runtime-consuming security checks (in fact, almost all time is spent in
AccessController.checkPermission).
See also bug 258705, which caused the modification of
Plugin.isDebugging(). (https://bugs.eclipse.org/bugs/show_bug.cgi?id=258705

Now I'm not sure if this issue should be solved at platform level or at
EMF Validation API level. The latter seems to be easier to be done by
simply caching the debug option...

(I'll post some profiling data later)

Thanks,
Mario

Re: [Validation] Deterioration of performance with Eclipse Galileo due to Tracing [message #431690 is a reply to message #431689]

Tue, 21 July 2009 12:19

Eclipse User

The profiling data:

This call tree shows that most of the validation time is spent on
calling Trace.entering and Trace.exiting (98.1%):
http://project-management.at/others/eclipse/Call_Tree_Transa ctionImpl_validate.html

The same call tree again but a little bit more expanded (the page is
static and clicking on the small 'plus' icons doesn't work...):
http://project-management.at/others/eclipse/Call_Tree_Transa ctionImpl_validate_expanded.html

And now the real cause of this performance problem: Plugin.isDebugging
http://project-management.at/others/eclipse/Call_Tree_Plugin _isDebugging.html

Mario

Mario Winterer schrieb:
> Hi!
>
> I've currently moved from eclipse 3.4 to eclipse 3.5 and I'm
> experiencing a huge performance penalty when using (live) validation.
>
> Especially when doing lots of modifications in one single EMF
> transaction, the live validation that is performed afterwards takes
> about 99% of the entire operation runtime.
>
> Operation runtime:
> + eclipse 3.4: about 10 seconds
> + eclipse 3.5: about 300 seconds
>
> Performance analysis show that almost all runtime is spent on testing if
> debugging is enabled (Tracing.shouldTrace invokes Plugin.isDebugging()).
>
> While in eclipse 3.4, Plugin.isDebugging() just returned a boolean field
> value, in eclipse 3.5 the debug options are queried which causes
> runtime-consuming security checks (in fact, almost all time is spent in
> AccessController.checkPermission).
> See also bug 258705, which caused the modification of
> Plugin.isDebugging(). (https://bugs.eclipse.org/bugs/show_bug.cgi?id=258705
>
> Now I'm not sure if this issue should be solved at platform level or at
> EMF Validation API level. The latter seems to be easier to be done by
> simply caching the debug option...
>
> (I'll post some profiling data later)
>
> Thanks,
> Mario

Re: [Validation] Deterioration of performance with Eclipse Galileo due to Tracing [message #431699 is a reply to message #431690]

Wed, 22 July 2009 05:36

Eclipse User

Hi Mario,

thanks for the detailed bug report.

It would probably be the most simple thing, to just cache the isDebugging
value. However the problem is not the caching itself, but keeping cache's
value coherent with the reality.

As the debugging/tracing option is relevant to the developers only, I'd be
tempted to insert this cache first and then wait for the platform to fix the
underlying issue.

Could you please open a bug on the validation component, I'll try to provide
a fix today afternoon and schedule followups with platform.

Thanks again for the detailed and helpful analysis,
Boris

Re: [Validation] Deterioration of performance with Eclipse Galileo due to Tracing [message #431700 is a reply to message #431699]

Wed, 22 July 2009 05:41

Eclipse User

Guys,

You might be interested it this bugzilla I filed 3 years ago:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=162347

Please consider voting for it! ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Boris Gruschko schrieb:
> Hi Mario,
>
> thanks for the detailed bug report.
>
> It would probably be the most simple thing, to just cache the
> isDebugging value. However the problem is not the caching itself, but
> keeping cache's value coherent with the reality.
>
> As the debugging/tracing option is relevant to the developers only,
> I'd be tempted to insert this cache first and then wait for the
> platform to fix the underlying issue.
>
> Could you please open a bug on the validation component, I'll try to
> provide a fix today afternoon and schedule followups with platform.
>
> Thanks again for the detailed and helpful analysis,
> Boris

Re: [Validation] Deterioration of performance with Eclipse Galileo due to Tracing [message #431703 is a reply to message #431700]

Wed, 22 July 2009 06:51

Eclipse User

Hm,

3 years ago wasn't 3.5M6 and the calls didn't take that long.

I'll open a bug for platform and relate it to 162347.

Cheers,
Boris

"Eike Stepper" <stepper@esc-net.de> wrote in message
news:h46mss$69n$3@build.eclipse.org...
> Guys,
>
> You might be interested it this bugzilla I filed 3 years ago:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=162347
>
> Please consider voting for it! ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Boris Gruschko schrieb:
>> Hi Mario,
>>
>> thanks for the detailed bug report.
>>
>> It would probably be the most simple thing, to just cache the
>> isDebugging value. However the problem is not the caching itself, but
>> keeping cache's value coherent with the reality.
>>
>> As the debugging/tracing option is relevant to the developers only,
>> I'd be tempted to insert this cache first and then wait for the
>> platform to fix the underlying issue.
>>
>> Could you please open a bug on the validation component, I'll try to
>> provide a fix today afternoon and schedule followups with platform.
>>
>> Thanks again for the detailed and helpful analysis,
>> Boris

Re: [Validation] Deterioration of performance with Eclipse Galileo due to Tracing [message #431718 is a reply to message #431700]

Wed, 22 July 2009 14:48

Eclipse User

I think, 3.5 now offers the interface DebugOptionsListener that can be
implemented and registered as service.

"Eike Stepper" <stepper@esc-net.de> schrieb im Newsbeitrag
news:h46mss$69n$3@build.eclipse.org...
> Guys,
>
> You might be interested it this bugzilla I filed 3 years ago:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=162347
>
> Please consider voting for it! ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Boris Gruschko schrieb:
>> Hi Mario,
>>
>> thanks for the detailed bug report.
>>
>> It would probably be the most simple thing, to just cache the
>> isDebugging value. However the problem is not the caching itself, but
>> keeping cache's value coherent with the reality.
>>
>> As the debugging/tracing option is relevant to the developers only,
>> I'd be tempted to insert this cache first and then wait for the
>> platform to fix the underlying issue.
>>
>> Could you please open a bug on the validation component, I'll try to
>> provide a fix today afternoon and schedule followups with platform.
>>
>> Thanks again for the detailed and helpful analysis,
>> Boris

Re: [Validation] Deterioration of performance with Eclipse Galileo due to Tracing [message #431723 is a reply to message #431699]

Wed, 22 July 2009 19:06

Eclipse User

I've filed bug #284348
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=284348).

"Boris Gruschko" <boris.gruschko@sap.com> schrieb im Newsbeitrag
news:h46mj6$i5n$1@build.eclipse.org...
> Hi Mario,
>
> thanks for the detailed bug report.
>
> It would probably be the most simple thing, to just cache the isDebugging
> value. However the problem is not the caching itself, but keeping cache's
> value coherent with the reality.
>
> As the debugging/tracing option is relevant to the developers only, I'd be
> tempted to insert this cache first and then wait for the platform to fix
> the underlying issue.
>
> Could you please open a bug on the validation component, I'll try to
> provide a fix today afternoon and schedule followups with platform.
>
> Thanks again for the detailed and helpful analysis,
> Boris

Previous Topic:	"getPackage() : EObject" returns for cross referenced model
Next Topic:	Classloader problem due to Teneo caching mechanism.

Goto Forum:

-=] Back to Top [=-

Current Time: Thu Jul 17 16:16:58 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter