Home » Modeling » EMF » Lazy-loading of classes in EMF
| |
| Re: Lazy-loading of classes in EMF [message #403858 is a reply to message #403857] |
Tue, 26 September 2006 16:48   |
 Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Ed,
Right now my collectNewChildDescriptors has 1056
newChildDescriptors.add() each corresponding to a c++ class. the library
is more than 10 years old and still alive, healthy and growing. I have
not moved to RCP yet and have been testing this plugin inside eclipse
itself. A new instance of eclipse starts with about 120M for me, loading
this plugin makes it over 500M which is seriously high.
I can divide the objects to different groups, but even that will create
a lot of object not needed necessarily. The best approach seems to be
lazy-loading. Why was the item provider designed this way? Why shouldn't
the object be created only when the user actually needs to create it, eg
by 'Create Child' > 'Object'?
Ed Merks wrote:
> Ali,
>
> This simply how XItemProvider.collectNewChildDescriptors works. You'd
> have to redesign that part of the framework if that's a problem for
> you. Surely your model is not so big that creating such instances
> becomes a serious memory problem?
>
>
> Ali wrote:
>> Hi,
>>
>> Assume modeling a package P consisting of n classes where n is a big
>> number. In the package P we create a class called X which is a
>> container of all the other n classes. After generating the code and
>> running the editor, by activating the class X (eg right-clicking to
>> create a child), EMF seems to start creating an instance of all the n
>> classes consuming a considerable memory. How is it possible to have a
>> lazy-loading class system in this case?
|
|
|
| Re: Lazy-loading of classes in EMF [message #403859 is a reply to message #403858] |
Tue, 26 September 2006 17:03 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Ali,
I doubt it's the actual creation of the objects taking up this much
memory. How big is each instance? Creating instances should be fast
since it's not unreasonable to expect that loading a resource would need
to create 10,000 instances or even 100,000 instances. A user is going
to have a hard time with a menu that has 1000 choices anyway, so perhaps
you should have some other mechanism for creating children for the root
and turn off child creation for those GenFeature of X. Even if we
didn't create an instance, we'd still need the text and icon for the
objects and those come from the plugins as well. In any event,
explaining the reason for the design (it's very simple to create objects
and then derive menu items based on those), won't result in the design
changing drastically...
Ali wrote:
> Ed,
>
> Right now my collectNewChildDescriptors has 1056
> newChildDescriptors.add() each corresponding to a c++ class. the
> library is more than 10 years old and still alive, healthy and
> growing. I have not moved to RCP yet and have been testing this plugin
> inside eclipse itself. A new instance of eclipse starts with about
> 120M for me, loading this plugin makes it over 500M which is seriously
> high.
>
> I can divide the objects to different groups, but even that will
> create a lot of object not needed necessarily. The best approach seems
> to be lazy-loading. Why was the item provider designed this way? Why
> shouldn't the object be created only when the user actually needs to
> create it, eg by 'Create Child' > 'Object'?
>
>
> Ed Merks wrote:
>> Ali,
>>
>> This simply how XItemProvider.collectNewChildDescriptors works.
>> You'd have to redesign that part of the framework if that's a problem
>> for you. Surely your model is not so big that creating such
>> instances becomes a serious memory problem?
>>
>>
>> Ali wrote:
>>> Hi,
>>>
>>> Assume modeling a package P consisting of n classes where n is a big
>>> number. In the package P we create a class called X which is a
>>> container of all the other n classes. After generating the code and
>>> running the editor, by activating the class X (eg right-clicking to
>>> create a child), EMF seems to start creating an instance of all the
>>> n classes consuming a considerable memory. How is it possible to
>>> have a lazy-loading class system in this case?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Lazy-loading of classes in EMF [message #403861 is a reply to message #403859] |
Tue, 26 September 2006 17:15 |
Auerliano
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Ed,
In this case, I will investigate this for memory leaks.
By the way, another problem with generating mega-codes in EMF is that
one single method may end up with being more than 64kb(?) where java
does not compile it. I had this problem with doSwitch() and breaking the
code to packages helped this.
Ed Merks wrote:
> Ali,
>
> I doubt it's the actual creation of the objects taking up this much
> memory. How big is each instance? Creating instances should be fast
> since it's not unreasonable to expect that loading a resource would need
> to create 10,000 instances or even 100,000 instances. A user is going
> to have a hard time with a menu that has 1000 choices anyway, so perhaps
> you should have some other mechanism for creating children for the root
> and turn off child creation for those GenFeature of X. Even if we
> didn't create an instance, we'd still need the text and icon for the
> objects and those come from the plugins as well. In any event,
> explaining the reason for the design (it's very simple to create objects
> and then derive menu items based on those), won't result in the design
> changing drastically...
>
>
> Ali wrote:
>> Ed,
>>
>> Right now my collectNewChildDescriptors has 1056
>> newChildDescriptors.add() each corresponding to a c++ class. the
>> library is more than 10 years old and still alive, healthy and
>> growing. I have not moved to RCP yet and have been testing this plugin
>> inside eclipse itself. A new instance of eclipse starts with about
>> 120M for me, loading this plugin makes it over 500M which is seriously
>> high.
>>
>> I can divide the objects to different groups, but even that will
>> create a lot of object not needed necessarily. The best approach seems
>> to be lazy-loading. Why was the item provider designed this way? Why
>> shouldn't the object be created only when the user actually needs to
>> create it, eg by 'Create Child' > 'Object'?
>>
>>
>> Ed Merks wrote:
>>> Ali,
>>>
>>> This simply how XItemProvider.collectNewChildDescriptors works.
>>> You'd have to redesign that part of the framework if that's a problem
>>> for you. Surely your model is not so big that creating such
>>> instances becomes a serious memory problem?
>>>
>>>
>>> Ali wrote:
>>>> Hi,
>>>>
>>>> Assume modeling a package P consisting of n classes where n is a big
>>>> number. In the package P we create a class called X which is a
>>>> container of all the other n classes. After generating the code and
>>>> running the editor, by activating the class X (eg right-clicking to
>>>> create a child), EMF seems to start creating an instance of all the
>>>> n classes consuming a considerable memory. How is it possible to
>>>> have a lazy-loading class system in this case?
|
|
|
| Re: Lazy-loading of classes in EMF [message #403864 is a reply to message #403861] |
Tue, 26 September 2006 17:38 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Ali,
Yes, the Java 64K byte code limit is particularly annoying when
generating code because you can't really know from the source code
whether something will be too big after being converted to byte code.
I've not seen a model so big that the switch itself leads to this. It
is generally a good idea to compose a model from logical groupings that
are small enough to be mentally consumable...
Ali wrote:
> Ed,
>
> In this case, I will investigate this for memory leaks.
>
> By the way, another problem with generating mega-codes in EMF is that
> one single method may end up with being more than 64kb(?) where java
> does not compile it. I had this problem with doSwitch() and breaking
> the code to packages helped this.
>
>
> Ed Merks wrote:
>> Ali,
>>
>> I doubt it's the actual creation of the objects taking up this much
>> memory. How big is each instance? Creating instances should be fast
>> since it's not unreasonable to expect that loading a resource would
>> need to create 10,000 instances or even 100,000 instances. A user is
>> going to have a hard time with a menu that has 1000 choices anyway,
>> so perhaps you should have some other mechanism for creating children
>> for the root and turn off child creation for those GenFeature of X.
>> Even if we didn't create an instance, we'd still need the text and
>> icon for the objects and those come from the plugins as well. In
>> any event, explaining the reason for the design (it's very simple to
>> create objects and then derive menu items based on those), won't
>> result in the design changing drastically...
>>
>>
>> Ali wrote:
>>> Ed,
>>>
>>> Right now my collectNewChildDescriptors has 1056
>>> newChildDescriptors.add() each corresponding to a c++ class. the
>>> library is more than 10 years old and still alive, healthy and
>>> growing. I have not moved to RCP yet and have been testing this
>>> plugin inside eclipse itself. A new instance of eclipse starts with
>>> about 120M for me, loading this plugin makes it over 500M which is
>>> seriously high.
>>>
>>> I can divide the objects to different groups, but even that will
>>> create a lot of object not needed necessarily. The best approach
>>> seems to be lazy-loading. Why was the item provider designed this
>>> way? Why shouldn't the object be created only when the user actually
>>> needs to create it, eg by 'Create Child' > 'Object'?
>>>
>>>
>>> Ed Merks wrote:
>>>> Ali,
>>>>
>>>> This simply how XItemProvider.collectNewChildDescriptors works.
>>>> You'd have to redesign that part of the framework if that's a
>>>> problem for you. Surely your model is not so big that creating
>>>> such instances becomes a serious memory problem?
>>>>
>>>>
>>>> Ali wrote:
>>>>> Hi,
>>>>>
>>>>> Assume modeling a package P consisting of n classes where n is a
>>>>> big number. In the package P we create a class called X which is a
>>>>> container of all the other n classes. After generating the code
>>>>> and running the editor, by activating the class X (eg
>>>>> right-clicking to create a child), EMF seems to start creating an
>>>>> instance of all the n classes consuming a considerable memory. How
>>>>> is it possible to have a lazy-loading class system in this case?
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Lazy-loading of classes in EMF [message #531608 is a reply to message #531601] |
Wed, 05 May 2010 14:25 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Bertrand,
Comments below.
Bertrand Daru wrote:
> Hi,
>
> The generated code in the doSwitch method should be refactored, using
> methods instead of recopy same repeat code fragments.
I understand the methods approach but I don't understand what "repeat
code fragments" you mean.
>
> I have a java class witch make this work and join it to this message.
I guess that didn't work...
>
> Although the resulting code may exceed 64k bytes, the resulting class
> compiles and works perfect !
Yes, even with the switch cases factored into more methods, one can
still exceed the limit.
>
> Best regards
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 00:07:13 GMT 2024
Powered by FUDForum. Page generated in 0.02212 seconds |
] 
Search
Help
Register
Login
Home
