Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » Performance: logic in SourceProvider or activeWhen?
Performance: logic in SourceProvider or activeWhen? [message #554164] Fri, 20 August 2010 11:39 Go to next message
Rainer is currently offline RainerFriend
Messages: 6
Registered: July 2010
Junior Member
Hello,

in my plugin, I enable and disable commands by using SourceProviders.

Currently, the logic that decides about the enabling is located in the SourceProvider which then simply provides a String that is evaluated via <equals> in the <activeWhen> of the handler.

The more usual way seems to be providing a "real" part of my domain model via the SourceProvider which is then evaluated in the <activeWhen> using Eclipse expressions. But if that evaluation is rather complex (e.g. involving possibly large collections), I can imagine that this usual way is inferior performance-wise because I think that the activeWhen is way more often checked/called than my SourceProvider, which is only called manually by me.

My question is now simply if this assumption is true and I should therefore keep my evaluation logic in the SourceProvider (as Java code) and not move it to the plugin.xml (XML Eclipse expressions). An additional benefit would be that there only is one place where "real" evaluation (in the sense of doing more than just checking Strings) is done, namely the SourceProviders, rather than splitting that logic into a Java and an XML part.

I really want to comply with the standards but sacrificing performance would just not be worth it for me...

Greetings,
Rainer
Re: Performance: logic in SourceProvider or activeWhen? [message #554172 is a reply to message #554164] Fri, 20 August 2010 12:21 Go to previous message
Daniel Krügler is currently offline Daniel KrüglerFriend
Messages: 853
Registered: July 2009
Senior Member
On 20.08.2010 13:39, Rainer wrote:
> Hello,
>
> in my plugin, I enable and disable commands by using SourceProviders.
>
> Currently, the logic that decides about the enabling is located in the
> SourceProvider which then simply provides a String that is evaluated via
> <equals> in the <activeWhen> of the handler.
>
> The more usual way seems to be providing a "real" part of my domain
> model via the SourceProvider which is then evaluated in the <activeWhen>
> using Eclipse expressions. But if that evaluation is rather complex
> (e.g. involving possibly large collections), I can imagine that this
> usual way is inferior performance-wise because I think that the
> activeWhen is way more often checked/called than my SourceProvider,
> which is only called manually by me.
>
> My question is now simply if this assumption is true

This can not be answered in general. The right way to get an answer
for this question is to test, whether it makes a noticable difference
on *your* scenario.

> and I should
> therefore keep my evaluation logic in the SourceProvider (as Java code)
> and not move it to the plugin.xml (XML Eclipse expressions). An
> additional benefit would be that there only is one place where "real"
> evaluation (in the sense of doing more than just checking Strings) is
> done, namely the SourceProviders, rather than splitting that logic into
> a Java and an XML part.
>
> I really want to comply with the standards but sacrificing performance
> would just not be worth it for me...

There does not exist such a standard. Nevertheless, it is often useful
to separate concerns to reduce dependencies among actually unrelated
components. If the xml-expression evaluation is too slow you might
want to consider the combination of a PropertyTester defined by the
extension point org.eclipse.core.expressions.propertyTesters and
indirectly referred to by the "test" element within visibleWhen
or enabledWhen elements. The indirect reference happens via the
combination of property and args. The "property" shall denote
a valid concatenation of the namespace and one of the properties
listed in org.eclipse.core.expressions.propertyTesters. The "args"
property is a domain-specific way to extend the functionality of
a given PropertyTester. It is only provided to the PropertyTester
itself and thus depends on the meaning, the individual property
tester is defining for it. Thus, this is an API contract of a given
property tester. The advantage of this key-based approach is, that
a given property tester can easily extend it's set of know
arguments.

HTH & Greetings from Bremen,

Daniel Krügler
Previous Topic:How to eliminate a plugin from the run configuration?
Next Topic:FormEditor dirty but cannot save
Goto Forum:
  


Current Time: Sat Dec 20 17:22:47 GMT 2014

Powered by FUDForum. Page generated in 0.02056 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software