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 |
Stephan Herrmann 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
- maybe an annotation would be more suitable?
- what should be its name?
your invited to participate in this discussion
Stephan
|
|
|
Re: transient roles as a design option for performance? [message #657191 is a reply to message #657168] |
Tue, 01 March 2011 21:35 |
Olaf Otto 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 . 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 |
Stephan Herrmann 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
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?
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 |
Stephan Herrmann 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
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 #1749633 is a reply to message #689069] |
Thu, 08 December 2016 19:14 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
Hi Lars,
Lars Schuetze wrote on Mon, 05 December 2016 20:12Hi, 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
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
|
|
|
Goto Forum:
Current Time: Fri Mar 29 15:37:07 GMT 2024
Powered by FUDForum. Page generated in 0.03339 seconds
|