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

Help

Home

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

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

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

Tue, 21 July 2009 16:10

Mario Winterer

Messages: 136
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Tue, 21 July 2009 16:19

Mario Winterer

Messages: 136
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Wed, 22 July 2009 09:36

Boris Gruschko

Messages: 14
Registered: July 2009

Junior Member

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

Report message to a moderator

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

Wed, 22 July 2009 09:41

Eike Stepper

Messages: 6508
Registered: July 2009

Senior Member

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

Cheers
/Eike

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

Report message to a moderator

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

Wed, 22 July 2009 10:51

Boris Gruschko

Messages: 14
Registered: July 2009

Junior Member

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

Report message to a moderator

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

Wed, 22 July 2009 18:48

Mario Winterer

Messages: 136
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Wed, 22 July 2009 23:06

Mario Winterer

Messages: 136
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Sep 28 06:00:19 GMT 2020

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter