MooseDefaultState

On 23 Sep 2017, at 20:03, Cyril Ferlicot D. <[hidden email]> wrote:

Hi,

Can someone explain the real interest to get a dictionary for properties
and a dictionary for queries in the MooseDefaultState?

Is there a downside to merge both?

I did some tests by creating a SYNState using a single dictionary for
both properties and queries. Here is the memory impact:

MooseDefaultState
-------------------

Image without model : 263Mo

Image with model : 605Mo
Image with model and default synectique caches : 650Mo

Image with model, default caches and after using the application : 792Mo

SYNState
-------------------

Image without model : 263Mo
Image with model : 589Mo

Image with model and default synectique caches : 575Mo (There was
probably a full GC that garbaged the temporary object of the import)
Image with model, default caches and after using the application : 706Mo

We see a clear gain of memory. (I did exactly the same interactions in
both try)

We might be interested by this at Synectique. This is why I would like
to know the reasons to have two different dictionaries since there is no
class comment. If the difference will not impact our tools I'll make the
default state configurable and I will introduce this SYNState renaming
it "MooseMemoryEfficientState" if it is fine with everyone.

Thank you in advance for the infos.

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

On 23 Sep 2017, at 21:54, Cyril Ferlicot D. <[hidden email]> wrote:

Le 23/09/2017 à 21:01, Stéphane Ducasse a écrit :

I was thinking more about Moose, Seaside….. 
Because Pharo is not that large. Even if we can remove things. 
And the bootstrap is not really related to that. 

From Moose we get only FAME and FAMIX, but we can restrict a little more
FAMIX. I would like to make groups depending of the language because for
now we load everything for every language. Not loading the Smalltalk
package into non smalltalk technologies would help us to reduce the time
of queries.

For Seaside I opened an issue on Seaside issue tracker some weeks ago to
be able to load seaside without the tests. It will probably be done for
Seaside 3.3.

Then I think we use pretty much everything that we load on top of Pharo.

ok do you know when the queries dict is used?
Because this is the first time I hear about it. 

Here is the list of usages I see:

- MooseModel use it to save bookmarks
- FAMIXContainerEntity use it in #classes
- FAMIXNamespace use it for #methods
- FAMIXPackage use it for #classes, #concernedClassesCollection,
#extendedClasses, #extensionClasses, #extensionMethods, #localMethods
- Other FAMIXXXX use it that way
- MooseAbstractGroup use it in the #allModelXXX methods and
#allWithSubTypesOf:
…

--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org 
03 59 35 87 52
Assistant: Julie Jonas 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

On 24 Sep 2017, at 12:30, stephan <[hidden email]> wrote:

On 24-09-17 09:02, Stéphane Ducasse wrote:

Why that. All the metrics are specific to one entity.

Because I tend to calculate the same metric for a lot of entries.
The lookup can be shared, avoiding the need to store the keys in every entity.

Stephan
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev