[Pharo-project] how to find the memory size of an object graph
Hi, I have some problems with memory consumption in a Moose model. However, I do not quite know where the memory is spent. To solve this, I would need to know the amount of space occupied by the objects (and all the referenced objects subgraphs). I found Object>>sizeInMemory, but this only shows the size of the current object. What I would need is a graph traversal that does not break on cyclic graphs, and that accumulates the size of the objects. I thought of using Fuel for this. I tried to follow the instructions from here: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/D... and work with the debug facilities: (ConfigurationOfFuel project version: '1.8') load: #(FuelDebug). For small examples, it seems to work fine: FLAnalyzer newDefault setDebug; analysisFor: #((1) (2) (3) (4)) However, for larger examples, the process takes forever. Is there another way of approaching this problem? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
On Mon, Jul 23, 2012 at 9:45 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I have some problems with memory consumption in a Moose model. However, I do not quite know where the memory is spent.
Even if it is not 100% about YOUR object graph, maybe space tally helps you? Once you have the graph, evaluate: SpaceTally new printSpaceAnalysis and then see the file 'STspace.text'. That may give you an idea of what is going on.
To solve this, I would need to know the amount of space occupied by the objects (and all the referenced objects subgraphs).
I found Object>>sizeInMemory, but this only shows the size of the current object. What I would need is a graph traversal that does not break on cyclic graphs, and that accumulates the size of the objects.
Exactly. Notice also that #sizeInMemory is buggy since it does not take into account padding: 'a' sizeInMemory -> 5 but it actually should be 8. There is a method in the VM which answers the exact size...I wonder why we cannot expose that as a primitive....
I thought of using Fuel for this. I tried to follow the instructions from here:
http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/D...
and work with the debug facilities: (ConfigurationOfFuel project version: '1.8') load: #(FuelDebug).
For small examples, it seems to work fine: FLAnalyzer newDefault setDebug; analysisFor: #((1) (2) (3) (4))
However, for larger examples, the process takes forever.
Yes, it is not useful, because Fuel format has nothing to do.
Is there another way of approaching this problem?
Here I attach a quick/simple graph traversal. Just subclass and implement #doInterception: Cheers, -- Mariano http://marianopeck.wordpress.com
On Jul 23, 2012, at 9:55 AM, Mariano Martinez Peck wrote:
On Mon, Jul 23, 2012 at 9:45 AM, Tudor Girba <tudor@tudorgirba.com> wrote: Hi,
I have some problems with memory consumption in a Moose model. However, I do not quite know where the memory is spent.
Even if it is not 100% about YOUR object graph, maybe space tally helps you? Once you have the graph, evaluate:
SpaceTally new printSpaceAnalysis
and then see the file 'STspace.text'. That may give you an idea of what is going on.
To solve this, I would need to know the amount of space occupied by the objects (and all the referenced objects subgraphs).
I found Object>>sizeInMemory, but this only shows the size of the current object. What I would need is a graph traversal that does not break on cyclic graphs, and that accumulates the size of the objects.
Exactly. Notice also that #sizeInMemory is buggy since it does not take into account padding: 'a' sizeInMemory -> 5 but it actually should be 8. There is a method in the VM which answers the exact size...I wonder why we cannot expose that as a primitiveâ¦.
Mariano can you open a specific thread on this point because we need better tools.
I thought of using Fuel for this. I tried to follow the instructions from here: http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/D...
and work with the debug facilities: (ConfigurationOfFuel project version: '1.8') load: #(FuelDebug).
For small examples, it seems to work fine: FLAnalyzer newDefault setDebug; analysisFor: #((1) (2) (3) (4))
However, for larger examples, the process takes forever.
Yes, it is not useful, because Fuel format has nothing to do.
Is there another way of approaching this problem?
Here I attach a quick/simple graph traversal. Just subclass and implement #doInterception:
Cheers,
-- Mariano http://marianopeck.wordpress.com
<GraphTraverser.st>
participants (3)
-
Mariano Martinez Peck -
Stéphane Ducasse -
Tudor Girba