Home » Modeling » EMF » Interface optimization
| |
| Re: Interface optimization [message #1067471 is a reply to message #1067468] |
Mon, 08 July 2013 20:45   |
 Ed Willink
Messages: 7655
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 |
Ed Merks
Messages: 33140
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
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Interface optimization [message #1067493 is a reply to message #1067492] |
Tue, 09 July 2013 05:53 |
Ed Willink
Messages: 7655
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 |
Ed Merks
Messages: 33140
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
>>>>
>>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 01:49:49 GMT 2024
Powered by FUDForum. Page generated in 0.02984 seconds |
] 
Search
Help
Register
Login
Home
