Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » transient roles as a design option for performance?
transient roles as a design option for performance? [message #657168] Tue, 01 March 2011 19:24 Go to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Hi,

In my job I recently did a lot of performance tuning so it felt natural to give
some considerations to the performance of OT/J programs, too.
Unfortunately, I also have a good test candidate: my prototype for null-
annotation-checking (see my blog post) suffers from performance issues.

Looking into the prototype it seems that the number of role instances created
might be relevant. The OT/Equinox Monitor mentioned over 100000 instances of
just one particular role class (during a full build of the JDT/Core itself).

I know we had this discussion before, but normally we were asking if creating
those role instances could be avoided completely. However, not creating a role
would require a lot of dirty changes behind the scenes. Instead, I today started
to play with a slightly different idea:

Perhaps its not just the instantiation that costs valuable cycles but also the
book keeping, i.e. all accesses to the internal role cache.

Theory: for some roles we never actually care about their identity, they're just a
handle towards their base. In this case, it doesn't matter whether lifting always
returns the same role for a given base, or whether fresh roles are created,
perhaps many roles will only be requested once, anyway.

Idea: support a modifier to mark role classes where we don't care about state
and identity. In first experiments I boldly used "transient" for this purpose.

First numbers: from first micro-benchmarks (never trust a micro benchmark!)
I can report speed-ups between factor 8 and factor 1.5. The high result was
measured if only declared lifting was used, the low result if replace callin
bindings were used to trigger the lifting. Note, that in all experiments the
speed-up grows with the number of instances involved. So with 100000
instances I was back at a speed-up factor 3 even with callin dispatch involved.

The cool thing: this kind of change is muuuch easier to implement than the
full strategy of completely faking role instances. It's a quite local change which
doesn't break lots of things here and their.

Some questions:
* what could we break with this kind of optimization?
- perhaps we would disallow any fields in "transient" roles?
- would inheritance between "transient" and normal roles work?

* what's a good name for the thing?
- maybe re-using an existing modifier is too crude for this Smile
- maybe an annotation would be more suitable?
- what should be its name?

your invited to participate in this discussion Smile
Stephan
Re: transient roles as a design option for performance? [message #657191 is a reply to message #657168] Tue, 01 March 2011 21:35 Go to previous messageGo to next message
Olaf Otto is currently offline Olaf OttoFriend
Messages: 22
Registered: July 2009
Junior Member
Hi Stephan,

Nice one! Some quick thoughts on this:

First of, I'd probably like to see this performance issue backed by some profiling data Wink. But nevertheless, I think the entire issue is rooted in the fact that a team is simply the factory of role instances. As such, the team might indeed want to know about the scope of the instances it is managing, regardless of their state.

In fact, many well-established frameworks are gearing their users with internal DSLs to express this, such as e.g. @singleton (guice) or @Scope(...) annotations (spring). So I believe this is actually a well-established solution for the issue.

> what could we break with this kind of optimization

- What if a user annotated his role and then uses MyRole r = new MyRole(base); somewhere? What will happen to lowering when the same role instance is used across the inheritance hierarchy of a base?

- Since we're talking about shared state, we must also address concurrency and the semantics of base therein - imagine two different base instances concurrently referencing the same role - must we address synchronization in the OT infrastructure to support this? Does the OT user have the right tools to take care of potential concurrency issues in roles?

- What about persistence / serialization (IMO, since we're dealing with references, we should be fine there?)


> what's a good name for the thing?
I vote for scopes! And I'd quite agree using transient would be evil, so an annotation would probably be most suitable. I'm probably pro explicitness there, i.e. something like @Singleton seems fine to me.


Some more thoughts:
- Perhaps we should discuss the usage of annotations or custom keywords in general. I have the feeling we will have more ideas like this, and the question arises whether

public team class ...

could not just as well be expressed as

@Team
public class

i.e. when to use keywords and when to use annotations. Okay, this is sort of a bad example since since the team keywords has obvious compilation advantages... but you catch the drift.

But I'm getting carried away here, so let's stay with the main issue!

Regards,
Olaf

[Updated on: Tue, 01 March 2011 21:49]

Report message to a moderator

Re: transient roles as a design option for performance? [message #657673 is a reply to message #657191] Thu, 03 March 2011 15:52 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Olaf,

some of the questions you raise, let me think we might
actually be talking about two different optimizations:

As you speak about singleton and shared state, are you
thinking of re-using one single role instance for adapting
an arbitrary number of base instances?
That would actually be near-maximum optimization, but
requires heavy trickery, in order to always use the
correct base reference.

My current thinking was a cheaper trick, where we could
actually end up creating even more role instances:
What if we just cut out the cache lookup and create a
fresh new role every time we lift?

The reason why this is already an optimization lies
in the lookup within a large role cache (implemented
as a WeakHashMap). It is way more expensive to find
a role among 100000+ roles than creating a fresh one.

Yet, your reply reminds me that we should probably
think about both solutions together, so that adding one
solution now won't hinder us from adding another one
later.

In that light using annotations becomes a must Smile

As a generic approach I could think of
  @Instantiation(ALWAYS)
  @Instantiation(SINGLETON)
  @Instantiation(NEVER)
  @Instantiation(ONDEMAND)


Here's a quiz to see who is still awake:
Which option corresponds to the normal OT/J behavior?

Smile

best,
Stephan




Re: transient roles as a design option for performance? [message #657708 is a reply to message #657191] Thu, 03 March 2011 17:07 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
I still owe you a comment to this side issue:

Olaf Otto wrote on Tue, 01 March 2011 22:35

- Perhaps we should discuss the usage of annotations or custom keywords in general. I have the feeling we will have more ideas like this, and the question arises whether

public team class ...

could not just as well be expressed as

@Team
public class

i.e. when to use keywords and when to use annotations. Okay, this is sort of a bad example since since the team keywords has obvious compilation advantages... but you catch the drift.




Generally: keywords are a matter of language design,
annotations are a tool for (framework) developers.
If you need to tell your boss that OT/J is actually still Java
(for getting use of OT/J in projects approved) then, yes,
please say it's a library. However, the truth is: it's a language Smile

Unfortunately, we already see a few annotations out there,
that blur this border. Think of @Override: it is a modifier
whose placement is actually checked by the compiler.
Speaking of modifiers: for the following keywords I
actually don't see much difference if we write them with
or without an @:
 callin, before, replace, after, get set

(nothing gained nothing lost I'd say).

Indeed the keyword "team" plays a special role as this
is the main switch for enabling OT/J syntax (try to use
any other OT/J syntax (except for "within") in a file that
doesn't first have the "team" keyword).

But, please, let's not discuss:
 @BindReplace("void myRoleMethod(String s) <- void bm(int i)  with { s <- String.valueOf(i) }")


:-/

The reason why I'm content with @Instantiation is:
this is fine tuning of a language whose design is complete.
When used with care, program semantics will actually
not change by applying this annotation (the compiler
should help in checking this!).
Second: it's a modifier. Annotations are modifiers.
So this fits.

Does this sound consistent?
Stephan




Re: transient roles as a design option for performance? [message #686494 is a reply to message #657168] Wed, 22 June 2011 10:58 Go to previous messageGo to next message
Jan Marc Hoffmann is currently offline Jan Marc HoffmannFriend
Messages: 32
Registered: July 2009
Member
Funny, I did about the same tests. I faced heavy performance issues (3x+) when adding a role to the org.eclipse.jdt.core SingleName node and some other static methods in the Parser. My first guess was the role instantiation. But after some testing I did find out that the issues remain even after disabling the lifting. The problem faded after removing the playedBy relationships on heavy used nodes.

What about a profiler? Is any planed? And let me know if you got any version I might test with my project. :=)



Re: transient roles as a design option for performance? [message #689069 is a reply to message #686494] Sun, 26 June 2011 17:57 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Hi Jan Marc,

Jan Marc Hoffmann wrote on Wed, 22 June 2011 12:58
Funny, I did about the same tests. I faced heavy performance issues (3x+) when adding a role to the org.eclipse.jdt.core SingleName node and some other static methods in the Parser. My first guess was the role instantiation. But after some testing I did find out that the issues remain even after disabling the lifting. The problem faded after removing the playedBy relationships on heavy used nodes.


Let me ask: what do you mean by "disabling the lifting"? Was the last step ("removing the playedBy relationships") really just affecting playedBy, or did you still have some callin etc. that were removed during the same step?

Quote:

What about a profiler? Is any planed?


I definitely don't want to write a profiler, however, testing whether/how existing tools like MAT, RAT etc. work with OT/J should be a worthwhile task.

Quote:

And let me know if you got any version I might test with my project. :=)


You mean version of the annotations discussed in this thread? Maybe I forgot to announce what has actually been implemented? See the N&N and the OTJLD!

best,
Stephan
Re: transient roles as a design option for performance? [message #691127 is a reply to message #689069] Thu, 30 June 2011 19:20 Go to previous messageGo to next message
Jan Marc Hoffmann is currently offline Jan Marc HoffmannFriend
Messages: 32
Registered: July 2009
Member
Stephan Herrmann wrote on Sun, 26 June 2011 13:57


Jan Marc Hoffmann wrote on Wed, 22 June 2011 12:58
Funny, I did about the same tests. I faced heavy performance issues (3x+) when adding a role to the org.eclipse.jdt.core SingleName node and some other static methods in the Parser. My first guess was the role instantiation. But after some testing I did find out that the issues remain even after disabling the lifting. The problem faded after removing the playedBy relationships on heavy used nodes.


Let me ask: what do you mean by "disabling the lifting"? Was the last step ("removing the playedBy relationships") really just affecting playedBy, or did you still have some callin etc. that were removed during the same step?


With "disabling the lifting" I meant removing the callin bindings. I did evaluate several steps. The first step was removing frequent callins, the next was removing callin bindings and the last was removing the playedBy relationship. Only the last step did really improve performance. But the Parser might be a special case since its tuned for performance and the additional weaved control flows might cause the performance problems. But still it might be worthwhile to check this behaviour. Since it has been some time I last tested it I might create a small test case we might use to find out if there are any spots to tune.

Stephan Herrmann wrote on Sun, 26 June 2011 13:57

Quote:

And let me know if you got any version I might test with my project. :=)


You mean version of the annotations discussed in this thread? Maybe I forgot to announce what has actually been implemented? See the N&N and the OTJLD!


Thanks those changes will help but they won't fix my main problem described above. But they might come in handy at other spots in my app. :=) And yes evaluating an existing profiler for OT teams might be useful since finding bottlenecks might be even more difficult than with using regular java code only.
Re: transient roles as a design option for performance? [message #692475 is a reply to message #691127] Mon, 04 July 2011 14:05 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Jan Marc Hoffmann wrote on Thu, 30 June 2011 21:20


[...] I did evaluate several steps. The first step was removing frequent callins, the next was removing callin bindings and the last was removing the playedBy relationship. Only the last step did really improve performance.

I'm actually surprised: if only the playedBy binding remains this should have very limited impact. Were you still creating (explicitly?) lots of roles of that type?

Quote:
But the Parser might be a special case since its tuned for performance and the additional weaved control flows might cause the performance problems. But still it might be worthwhile to check this behaviour. Since it has been some time I last tested it I might create a small test case we might use to find out if there are any spots to tune.

A test case would be lovely.

Quote:

Thanks those changes will help but they won't fix my main problem described above. But they might come in handy at other spots in my app. :=)

It might even help, iff instantiation is the issue. It'd be cool to find out.

best,
Stephan

Re: transient roles as a design option for performance? [message #1749354 is a reply to message #692475] Mon, 05 December 2016 19:12 Go to previous messageGo to next message
Lars Schütze is currently offline Lars SchützeFriend
Messages: 43
Registered: March 2012
Location: Germany
Member

Hi, sorry for hijacking such an old topic (from 2011 -- 5 years ago). Has there been any further movements regarding these lightweight roles? I can think of that many domains use roles to represent concepts in their domain as wrappers around some base.
Re: transient roles as a design option for performance? [message #1749633 is a reply to message #689069] Thu, 08 December 2016 19:14 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Hi Lars,

Lars Schuetze wrote on Mon, 05 December 2016 20:12
Hi, sorry for hijacking such an old topic (from 2011 -- 5 years ago). Has there been any further movements regarding these lightweight roles? I can think of that many domains use roles to represent concepts in their domain as wrappers around some base.


Good you found this Smile

Did you see my "announcement":

Stephan Herrmann wrote on Sun, 26 June 2011 19:57
... Maybe I forgot to announce what has actually been implemented? See the N&N and the OTJLD!


(updating the 2nd link: http://help.eclipse.org/neon/topic/org.eclipse.objectteams.otdt.doc/guide/otjld/def/s2.html#s2.3.1.d)

Apparently, I forgot this myself, otherwise I would've mentioned this to you before :-/

That's the state we have, in particular:

  • ONDEMAND (default)
  • ALWAYS : implemented
  • NEVER : not yet implemented
  • SINGLETON : not yet implemented

The latter two would add signifcant complexity to the compiler, so I never took the courage to really go that road :-/

cheers,
Stephan

[Updated on: Thu, 08 December 2016 19:19]

Report message to a moderator

Previous Topic:Lifting and Roles - Graph Product Line example
Next Topic:eclipse neon product does not load new weaver
Goto Forum:
  


Current Time: Fri Mar 29 15:37:07 GMT 2024

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

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

Back to the top