23 Sep
2017
23 Sep
'17
8:03 p.m.
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
23 Sep
23 Sep
8:12 p.m.
On 23 Sep 2017, at 20:03, Cyril Ferlicot D.
<cyril.ferlicot(a)gmail.com> wrote:
Hi,
Can someone explain the real interest to get a dictionary for properties
and a dictionary for queries in the MooseDefaultState?
cyril can you explain to me what is for queries?
Did you check if there are smalldictionary?
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
Just loading the code takes that amount of space?
Are you sure that we use all that?
Image with model : 605Mo
Image with model and default synectique caches : 650Mo
What is a synectique
caches?
Image with model, default caches and after using the
application : 792Mo
SYNState
-------------------
Image without model : 263Mo
Image with model : 589Mo
so this is 6 mo so 1%?
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.
Yes I would like to know.
Do you know if the keys of “queries” clash with the keys of properties?
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--------------------------------------------
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
9:41 p.m.
On 23-09-17 20:03, Cyril Ferlicot D. wrote:
Can someone explain the real interest to get a
dictionary for
properties and a dictionary for queries in the MooseDefaultState?
Properties should probably not be a dictionary. There are way too many
MooseEntities that share the same entries
Stephan
24 Sep
24 Sep
9:02 a.m.
Why that. All the metrics are specific to one entity.
On 23 Sep 2017, at 21:41, stephan
<stephan(a)stack.nl> wrote:
On 23-09-17 20:03, Cyril Ferlicot D. wrote:
--------------------------------------------
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
Can someone explain the real interest to get a
dictionary for properties and a dictionary for queries in the MooseDefaultState?
Properties should probably not be a dictionary. There are way too many MooseEntities
that share the same entries
Stephan
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
9:09 a.m.
When I take the default moose 60 image I get 63,3 m
So I do not understand if from moose you only use
Famix and Fame
and seaside
how is it possible that you end up with an image without model at 263.
Did you flush the MC caches or history?
Stef
On 23 Sep 2017, at 20:03, Cyril Ferlicot D.
<cyril.ferlicot(a)gmail.com> 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--------------------------------------------
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
10:50 a.m.
Le 24/09/2017 à 09:09, Stéphane Ducasse a écrit :
When I take the default moose 60 image I get 63,3 m
So I do not understand if from moose you only use
Famix and Fame
and seaside
how is it possible that you end up with an image without model at 263.
Did you flush the MC caches or history?
No, I did not took the time to check this kind of things. It would be
really cool if there was a package with help for the deployment or a
good documentation because I don't have time to check everything by myself.
Stef
--------------------------------------------
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
4:26 p.m.
On 24 Sep 2017, at 12:30, stephan
<stephan(a)stack.nl> wrote:
On 24-09-17 09:02, Stéphane Ducasse wrote:
I still do not get it.
You need a key per entity if you want to have a metric value per entity.
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--------------------------------------------
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
7:29 p.m.
Le 24/09/2017 à 12:30, stephan a écrit :
On 24-09-17 09:02, Stéphane Ducasse wrote:
If you have a solution to reduce the memory by sharing the keys without
losing in perf I am interested :)
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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
2408
days inactive
2409
days old
8 comments
3 participants
participants (3)
-
Cyril Ferlicot D. -
stephan -
Stéphane Ducasse