Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Interface optimization
Interface optimization [message #1067466] Mon, 08 July 2013 20:02 Go to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi

Given a simple model such as:

package my : my = 'my'
{
class A
{
operation op() : String[?];
}
class B extends A
{
operation op() : String[?];
}
}

Clearly A::op() must appear in A.java and AImpl.java, but is there a way
to avoid B::op() appearing in both B.java and BImpl.java (when
BImpl.java is sufficient)?

This optimization becomes quite significant when examing the amount of
generated into initializePackageContents when there are many derived
implementations of an interface and when the operation has a complex
signature.

Regards

Ed Willink
Re: Interface optimization [message #1067468 is a reply to message #1067466] Mon, 08 July 2013 20:21 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26050
Registered: July 2009
Senior Member
Ed,

An EAnnotation as produced by
org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EOperation,
boolean) on B's declaration of op does the trick, in terms of the
generated interface for B, but that has no impact on the amount of
metadata in the Ecore model; there are two declarations and they must be
represented as such. Unless you specify a body annotation for the
declaration of op in B so that something useful (and different from
AImpl)l is generated in BImpl, that declaration is kind of pointless...


On 08/07/2013 10:02 PM, Ed Willink wrote:
> Hi
>
> Given a simple model such as:
>
> package my : my = 'my'
> {
> class A
> {
> operation op() : String[?];
> }
> class B extends A
> {
> operation op() : String[?];
> }
> }
>
> Clearly A::op() must appear in A.java and AImpl.java, but is there a
> way to avoid B::op() appearing in both B.java and BImpl.java (when
> BImpl.java is sufficient)?
>
> This optimization becomes quite significant when examing the amount of
> generated into initializePackageContents when there are many derived
> implementations of an interface and when the operation has a complex
> signature.
>
> Regards
>
> Ed Willink
Re: Interface optimization [message #1067471 is a reply to message #1067468] Mon, 08 July 2013 20:45 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi

Thanks, SuppressedVisibility fixes the interface, but since it was the
metadata that is costing, it doesn't help.

Yes. My many derived implementations have distinctive bodies.

There is just one declaration A::op() in the interface. It may have many
derived implementations, but surely only the interface need appear in
the metadata?

Regards

Ed Willink

On 08/07/2013 21:21, Ed Merks wrote:
> Ed,
>
> An EAnnotation as produced by
> org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EOperation,
> boolean) on B's declaration of op does the trick, in terms of the
> generated interface for B, but that has no impact on the amount of
> metadata in the Ecore model; there are two declarations and they must
> be represented as such. Unless you specify a body annotation for the
> declaration of op in B so that something useful (and different from
> AImpl)l is generated in BImpl, that declaration is kind of pointless...
>
>
> On 08/07/2013 10:02 PM, Ed Willink wrote:
>> Hi
>>
>> Given a simple model such as:
>>
>> package my : my = 'my'
>> {
>> class A
>> {
>> operation op() : String[?];
>> }
>> class B extends A
>> {
>> operation op() : String[?];
>> }
>> }
>>
>> Clearly A::op() must appear in A.java and AImpl.java, but is there a
>> way to avoid B::op() appearing in both B.java and BImpl.java (when
>> BImpl.java is sufficient)?
>>
>> This optimization becomes quite significant when examing the amount
>> of generated into initializePackageContents when there are many
>> derived implementations of an interface and when the operation has a
>> complex signature.
>>
>> Regards
>>
>> Ed Willink
>
Re: Interface optimization [message #1067492 is a reply to message #1067471] Tue, 09 July 2013 05:40 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26050
Registered: July 2009
Senior Member
Ed,

The metadata for each operation declaration is what carries the body and
it is needed by eInvoke. Even in Java the full metadata for the
signature is duplicated in each and every method declaration and
definition, even across the interface's declaration and the classes
definition. If it's byte code reduction for package initialization you
seek, Initialize by Loading accomplishes that purpose quite
effectively. If it's the memory footprint of the model itself you seek
to minimize, it's hard to imagine that the size of the metamodel will
generally be significant relative to the size of all the instances...

On 08/07/2013 10:45 PM, Ed Willink wrote:
> Hi
>
> Thanks, SuppressedVisibility fixes the interface, but since it was the
> metadata that is costing, it doesn't help.
>
> Yes. My many derived implementations have distinctive bodies.
>
> There is just one declaration A::op() in the interface. It may have
> many derived implementations, but surely only the interface need
> appear in the metadata?
>
> Regards
>
> Ed Willink
>
> On 08/07/2013 21:21, Ed Merks wrote:
>> Ed,
>>
>> An EAnnotation as produced by
>> org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EOperation,
>> boolean) on B's declaration of op does the trick, in terms of the
>> generated interface for B, but that has no impact on the amount of
>> metadata in the Ecore model; there are two declarations and they must
>> be represented as such. Unless you specify a body annotation for the
>> declaration of op in B so that something useful (and different from
>> AImpl)l is generated in BImpl, that declaration is kind of pointless...
>>
>>
>> On 08/07/2013 10:02 PM, Ed Willink wrote:
>>> Hi
>>>
>>> Given a simple model such as:
>>>
>>> package my : my = 'my'
>>> {
>>> class A
>>> {
>>> operation op() : String[?];
>>> }
>>> class B extends A
>>> {
>>> operation op() : String[?];
>>> }
>>> }
>>>
>>> Clearly A::op() must appear in A.java and AImpl.java, but is there a
>>> way to avoid B::op() appearing in both B.java and BImpl.java (when
>>> BImpl.java is sufficient)?
>>>
>>> This optimization becomes quite significant when examing the amount
>>> of generated into initializePackageContents when there are many
>>> derived implementations of an interface and when the operation has a
>>> complex signature.
>>>
>>> Regards
>>>
>>> Ed Willink
>>
>
Re: Interface optimization [message #1067493 is a reply to message #1067492] Tue, 09 July 2013 05:53 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4046
Registered: July 2009
Senior Member
Hi Ed

My main concern is the extra start up time of 8 object/8 lines of
initialization for each of the derived operations. The extra code is a
secondary concer. Initialize by loading just makes the startup time even
worse.

At present the derived methods have all been manually pasted with an
@generated NOT so they have no modeling overhead. Attempting to replace
the manual pastes by modeled autogeneration incurs this unexpected
modeling overhead. It seems that Class/insert.javajetinc will be a much
better solution for unmodeled autogeneration.

Regards

Ed Willink


On 09/07/2013 06:40, Ed Merks wrote:
> Ed,
>
> The metadata for each operation declaration is what carries the body
> and it is needed by eInvoke. Even in Java the full metadata for the
> signature is duplicated in each and every method declaration and
> definition, even across the interface's declaration and the classes
> definition. If it's byte code reduction for package initialization
> you seek, Initialize by Loading accomplishes that purpose quite
> effectively. If it's the memory footprint of the model itself you
> seek to minimize, it's hard to imagine that the size of the metamodel
> will generally be significant relative to the size of all the
> instances...
>
> On 08/07/2013 10:45 PM, Ed Willink wrote:
>> Hi
>>
>> Thanks, SuppressedVisibility fixes the interface, but since it was
>> the metadata that is costing, it doesn't help.
>>
>> Yes. My many derived implementations have distinctive bodies.
>>
>> There is just one declaration A::op() in the interface. It may have
>> many derived implementations, but surely only the interface need
>> appear in the metadata?
>>
>> Regards
>>
>> Ed Willink
>>
>> On 08/07/2013 21:21, Ed Merks wrote:
>>> Ed,
>>>
>>> An EAnnotation as produced by
>>> org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EOperation,
>>> boolean) on B's declaration of op does the trick, in terms of the
>>> generated interface for B, but that has no impact on the amount of
>>> metadata in the Ecore model; there are two declarations and they
>>> must be represented as such. Unless you specify a body annotation
>>> for the declaration of op in B so that something useful (and
>>> different from AImpl)l is generated in BImpl, that declaration is
>>> kind of pointless...
>>>
>>>
>>> On 08/07/2013 10:02 PM, Ed Willink wrote:
>>>> Hi
>>>>
>>>> Given a simple model such as:
>>>>
>>>> package my : my = 'my'
>>>> {
>>>> class A
>>>> {
>>>> operation op() : String[?];
>>>> }
>>>> class B extends A
>>>> {
>>>> operation op() : String[?];
>>>> }
>>>> }
>>>>
>>>> Clearly A::op() must appear in A.java and AImpl.java, but is there
>>>> a way to avoid B::op() appearing in both B.java and BImpl.java
>>>> (when BImpl.java is sufficient)?
>>>>
>>>> This optimization becomes quite significant when examing the amount
>>>> of generated into initializePackageContents when there are many
>>>> derived implementations of an interface and when the operation has
>>>> a complex signature.
>>>>
>>>> Regards
>>>>
>>>> Ed Willink
>>>
>>
>
Re: Interface optimization [message #1067500 is a reply to message #1067493] Tue, 09 July 2013 06:26 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26050
Registered: July 2009
Senior Member
Ed,

Are your concerns based on measurements or is it of an abstract nature?

One could imagine using binary serialization to avoid the cost of
parsing XML and to reduce the serialized footprint, but in the end, yes,
the same instances need to be constructed one way or the other, and yes
these instances are needed, so no, they can't be optimized away.


On 09/07/2013 7:53 AM, Ed Willink wrote:
> Hi Ed
>
> My main concern is the extra start up time of 8 object/8 lines of
> initialization for each of the derived operations. The extra code is a
> secondary concer. Initialize by loading just makes the startup time
> even worse.
>
> At present the derived methods have all been manually pasted with an
> @generated NOT so they have no modeling overhead. Attempting to
> replace the manual pastes by modeled autogeneration incurs this
> unexpected modeling overhead. It seems that Class/insert.javajetinc
> will be a much better solution for unmodeled autogeneration.
>
> Regards
>
> Ed Willink
>
>
> On 09/07/2013 06:40, Ed Merks wrote:
>> Ed,
>>
>> The metadata for each operation declaration is what carries the body
>> and it is needed by eInvoke. Even in Java the full metadata for the
>> signature is duplicated in each and every method declaration and
>> definition, even across the interface's declaration and the classes
>> definition. If it's byte code reduction for package initialization
>> you seek, Initialize by Loading accomplishes that purpose quite
>> effectively. If it's the memory footprint of the model itself you
>> seek to minimize, it's hard to imagine that the size of the metamodel
>> will generally be significant relative to the size of all the
>> instances...
>>
>> On 08/07/2013 10:45 PM, Ed Willink wrote:
>>> Hi
>>>
>>> Thanks, SuppressedVisibility fixes the interface, but since it was
>>> the metadata that is costing, it doesn't help.
>>>
>>> Yes. My many derived implementations have distinctive bodies.
>>>
>>> There is just one declaration A::op() in the interface. It may have
>>> many derived implementations, but surely only the interface need
>>> appear in the metadata?
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>> On 08/07/2013 21:21, Ed Merks wrote:
>>>> Ed,
>>>>
>>>> An EAnnotation as produced by
>>>> org.eclipse.emf.ecore.util.EcoreUtil.setSuppressedVisibility(EOperation,
>>>> boolean) on B's declaration of op does the trick, in terms of the
>>>> generated interface for B, but that has no impact on the amount of
>>>> metadata in the Ecore model; there are two declarations and they
>>>> must be represented as such. Unless you specify a body annotation
>>>> for the declaration of op in B so that something useful (and
>>>> different from AImpl)l is generated in BImpl, that declaration is
>>>> kind of pointless...
>>>>
>>>>
>>>> On 08/07/2013 10:02 PM, Ed Willink wrote:
>>>>> Hi
>>>>>
>>>>> Given a simple model such as:
>>>>>
>>>>> package my : my = 'my'
>>>>> {
>>>>> class A
>>>>> {
>>>>> operation op() : String[?];
>>>>> }
>>>>> class B extends A
>>>>> {
>>>>> operation op() : String[?];
>>>>> }
>>>>> }
>>>>>
>>>>> Clearly A::op() must appear in A.java and AImpl.java, but is there
>>>>> a way to avoid B::op() appearing in both B.java and BImpl.java
>>>>> (when BImpl.java is sufficient)?
>>>>>
>>>>> This optimization becomes quite significant when examing the
>>>>> amount of generated into initializePackageContents when there are
>>>>> many derived implementations of an interface and when the
>>>>> operation has a complex signature.
>>>>>
>>>>> Regards
>>>>>
>>>>> Ed Willink
>>>>
>>>
>>
>
Previous Topic:[Teneo] new eobject reference is EObjectWithInverseResolvingEList
Next Topic:[Xcore] derived containment
Goto Forum:
  


Current Time: Fri Sep 19 05:50:30 GMT 2014

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

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