Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Mariano Martinez Peck
 


On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <[hidden email]> wrote:


On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <[hidden email]> wrote:

On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:

> Some notes:
>
> - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0?

Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :)
The method comment should probably highlight which definition is used.



So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?

I would like to compute the really used memory.

thanks

mariano
 

At the beginning I also thought to have 4, instead of 0. The problem is that if you put 4 and you have an object with and instVar that it is a SmallInteger, it will be counted twice, when actually it is only one.
That's why I thoguht 0 was better, since I want the really occupated memory. On the other hand, if you do "4 sizeInMemory" and see zero, I have to admit it is a litlte confusing.

The problem is that if I do for example:

Class >> spaceForInstances
    | totalSize |
    totalSize := 0.
    self allInstancesDo: [ :inst |
        totalSize := totalSize + inst sizeInMemory.
    ].
    ^ totalSize
 
SmallInteger spaceForInstances  ->>  0

So I don't know...maybe we have to answer 4 instead of 0?

Adrian what do you think?

>
> - In the line contentBytes := contentBytes + (self basicSize * bytesPerElement), why is contentBytes added because it should be always 0 because self class instSize should return 0 in case of variable classes. Or do I miss something?
You can have instance variables in variable classes:

ArrayedCollection variableSubclass: #TallyArray
       instanceVariableNames: 'tally'
       classVariableNames: ''
       poolDictionaries: ''
       category: 'Collections-Arrayed'

TallyArray instSize 1
(TallyArray new: 5) basicSize 5

Sure, they're not used very often in Squeak/Pharo since become: is so slow, but there's no theoretical reason why you can't for example implement Set as a variable subclass with a tally inst var.

>
> - Please remove the inline comment "inst vars"; if a comment is needed it should go into the main comment.
I agree, should be self-explanatory.

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Eliot Miranda-2
 


On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck <[hidden email]> wrote:
 


On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <[hidden email]> wrote:


On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <[hidden email]> wrote:

On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:

> Some notes:
>
> - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0?

Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :)
The method comment should probably highlight which definition is used.



So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?

0 bytes, obviously.  The only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot.
 

I would like to compute the really used memory.

thanks

mariano
 

At the beginning I also thought to have 4, instead of 0. The problem is that if you put 4 and you have an object with and instVar that it is a SmallInteger, it will be counted twice, when actually it is only one.
That's why I thoguht 0 was better, since I want the really occupated memory. On the other hand, if you do "4 sizeInMemory" and see zero, I have to admit it is a litlte confusing.

The problem is that if I do for example:

Class >> spaceForInstances
    | totalSize |
    totalSize := 0.
    self allInstancesDo: [ :inst |
        totalSize := totalSize + inst sizeInMemory.
    ].
    ^ totalSize
 
SmallInteger spaceForInstances  ->>  0

So I don't know...maybe we have to answer 4 instead of 0?

Adrian what do you think?

>
> - In the line contentBytes := contentBytes + (self basicSize * bytesPerElement), why is contentBytes added because it should be always 0 because self class instSize should return 0 in case of variable classes. Or do I miss something?
You can have instance variables in variable classes:

ArrayedCollection variableSubclass: #TallyArray
       instanceVariableNames: 'tally'
       classVariableNames: ''
       poolDictionaries: ''
       category: 'Collections-Arrayed'

TallyArray instSize 1
(TallyArray new: 5) basicSize 5

Sure, they're not used very often in Squeak/Pharo since become: is so slow, but there's no theoretical reason why you can't for example implement Set as a variable subclass with a tally inst var.

>
> - Please remove the inline comment "inst vars"; if a comment is needed it should go into the main comment.
I agree, should be self-explanatory.

Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project




Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Nicolas Cellier

2010/9/27 Eliot Miranda <[hidden email]>:

>
>
>
> On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>
>>
>>
>>
>> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>>
>>>
>>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <[hidden email]> wrote:
>>>>
>>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:
>>>>
>>>> > Some notes:
>>>> >
>>>> > - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0?
>>>>
>>>> Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :)
>>>> The method comment should probably highlight which definition is used.
>>>>
>>
>>
>> So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?
>
> 0 bytes, obviously.  The only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot.
>

Or from another POV, it's 4, the size of the slot. But we don't count
the size of the slots, they are already counted in the containing
object, that's why it should answer 0.

Nicolas

>>
>> I would like to compute the really used memory.
>>
>> thanks
>>
>> mariano
>>
>>>
>>> At the beginning I also thought to have 4, instead of 0. The problem is that if you put 4 and you have an object with and instVar that it is a SmallInteger, it will be counted twice, when actually it is only one.
>>> That's why I thoguht 0 was better, since I want the really occupated memory. On the other hand, if you do "4 sizeInMemory" and see zero, I have to admit it is a litlte confusing.
>>>
>>> The problem is that if I do for example:
>>>
>>> Class >> spaceForInstances
>>>     | totalSize |
>>>     totalSize := 0.
>>>     self allInstancesDo: [ :inst |
>>>         totalSize := totalSize + inst sizeInMemory.
>>>     ].
>>>     ^ totalSize
>>>
>>> SmallInteger spaceForInstances  ->>  0
>>>
>>> So I don't know...maybe we have to answer 4 instead of 0?
>>>
>>> Adrian what do you think?
>>>
>>>> >
>>>> > - In the line contentBytes := contentBytes + (self basicSize * bytesPerElement), why is contentBytes added because it should be always 0 because self class instSize should return 0 in case of variable classes. Or do I miss something?
>>>> You can have instance variables in variable classes:
>>>>
>>>> ArrayedCollection variableSubclass: #TallyArray
>>>>        instanceVariableNames: 'tally'
>>>>        classVariableNames: ''
>>>>        poolDictionaries: ''
>>>>        category: 'Collections-Arrayed'
>>>>
>>>> TallyArray instSize 1
>>>> (TallyArray new: 5) basicSize 5
>>>>
>>>> Sure, they're not used very often in Squeak/Pharo since become: is so slow, but there's no theoretical reason why you can't for example implement Set as a variable subclass with a tally inst var.
>>>>
>>>> >
>>>> > - Please remove the inline comment "inst vars"; if a comment is needed it should go into the main comment.
>>>> I agree, should be self-explanatory.
>>>>
>>>> Cheers,
>>>> Henry
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Mariano Martinez Peck
 


On Tue, Sep 28, 2010 at 6:46 AM, Nicolas Cellier <[hidden email]> wrote:

2010/9/27 Eliot Miranda <[hidden email]>:
>
>
>
> On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>
>>
>>
>>
>> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>>
>>>
>>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <[hidden email]> wrote:
>>>>
>>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:
>>>>
>>>> > Some notes:
>>>> >
>>>> > - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0?
>>>>
>>>> Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :)
>>>> The method comment should probably highlight which definition is used.
>>>>
>>
>>
>> So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?
>
> 0 bytes, obviously.  The only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot.
>

Or from another POV, it's 4, the size of the slot. But we don't count
the size of the slots, they are already counted in the containing
object, that's why it should answer 0.


Thanks for the answers. I finally let this:

sizeInMemory
    "Answer the number of bytes consumed by this instance including object header."
    | isCompact headerBytes contentBytes |

    "SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot. From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0."
    (self isMemberOf: SmallInteger) ifTrue: [^0].

     contentBytes := self class instSize * Smalltalk wordSize. "inst vars"

     self class isVariable ifTrue:[ |bytesPerElement|
            bytesPerElement := self class isBytes ifTrue: [1] ifFalse: [4].
            contentBytes := contentBytes + (self basicSize * bytesPerElement)].

     isCompact := self class indexIfCompact > 0.
      headerBytes :=
                    contentBytes > 255
                        ifTrue: [ 3 * Smalltalk wordSize ]
                        ifFalse: [isCompact ifTrue: [Smalltalk wordSize] ifFalse: [2 * Smalltalk wordSize]].
            ^ headerBytes + contentBytes


Now I wonder...maybe instead of doing this it is easier to have a primitive that just calls #internalByteSize: ?
The problem of course is that it needs changes in the vm...

cheers

Mariano
 

Nicolas

>>
>> I would like to compute the really used memory.
>>
>> thanks
>>
>> mariano
>>
>>>
>>> At the beginning I also thought to have 4, instead of 0. The problem is that if you put 4 and you have an object with and instVar that it is a SmallInteger, it will be counted twice, when actually it is only one.
>>> That's why I thoguht 0 was better, since I want the really occupated memory. On the other hand, if you do "4 sizeInMemory" and see zero, I have to admit it is a litlte confusing.
>>>
>>> The problem is that if I do for example:
>>>
>>> Class >> spaceForInstances
>>>     | totalSize |
>>>     totalSize := 0.
>>>     self allInstancesDo: [ :inst |
>>>         totalSize := totalSize + inst sizeInMemory.
>>>     ].
>>>     ^ totalSize
>>>
>>> SmallInteger spaceForInstances  ->>  0
>>>
>>> So I don't know...maybe we have to answer 4 instead of 0?
>>>
>>> Adrian what do you think?
>>>
>>>> >
>>>> > - In the line contentBytes := contentBytes + (self basicSize * bytesPerElement), why is contentBytes added because it should be always 0 because self class instSize should return 0 in case of variable classes. Or do I miss something?
>>>> You can have instance variables in variable classes:
>>>>
>>>> ArrayedCollection variableSubclass: #TallyArray
>>>>        instanceVariableNames: 'tally'
>>>>        classVariableNames: ''
>>>>        poolDictionaries: ''
>>>>        category: 'Collections-Arrayed'
>>>>
>>>> TallyArray instSize 1
>>>> (TallyArray new: 5) basicSize 5
>>>>
>>>> Sure, they're not used very often in Squeak/Pharo since become: is so slow, but there's no theoretical reason why you can't for example implement Set as a variable subclass with a tally inst var.
>>>>
>>>> >
>>>> > - Please remove the inline comment "inst vars"; if a comment is needed it should go into the main comment.
>>>> I agree, should be self-explanatory.
>>>>
>>>> Cheers,
>>>> Henry
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Henrik Sperre Johansen
In reply to this post by Nicolas Cellier


On Sep 28, 2010, at 6:46 40AM, Nicolas Cellier wrote:

>
> 2010/9/27 Eliot Miranda <[hidden email]>:
>>
>>
>>
>> On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>>
>>>
>>>
>>>
>>> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>>>
>>>>
>>>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <[hidden email]> wrote:
>>>>>
>>>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:
>>>>>
>>>>>> Some notes:
>>>>>>
>>>>>> - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0?
>>>>>
>>>>> Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :)
>>>>> The method comment should probably highlight which definition is used.
>>>>>
>>>
>>>
>>> So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?
>>
>> 0 bytes, obviously.  The only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot.
>>
>
> Or from another POV, it's 4, the size of the slot. But we don't count
> the size of the slots, they are already counted in the containing
> object, that's why it should answer 0.
>
> Nicolas

Yeah, those were the two I were thinking of, and Mariano also summed them up nicely in a previous mail.
When you want to use it for counting up total space usage of objects, 0 is the one it should answer.

Cheers.
Henry

P.S. I still stand by my statement that the comment should highlight this is the reason why 0 was chosen :)
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Henrik Sperre Johansen
In reply to this post by Mariano Martinez Peck
 

On Sep 28, 2010, at 9:36 27AM, Mariano Martinez Peck wrote:



On Tue, Sep 28, 2010 at 6:46 AM, Nicolas Cellier <[hidden email]> wrote:

2010/9/27 Eliot Miranda <[hidden email]>:
>
>
>
> On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>
>>
>>
>>
>> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>>
>>>
>>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <[hidden email]> wrote:
>>>>
>>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:
>>>>
>>>> > Some notes:
>>>> >
>>>> > - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0?
>>>>
>>>> Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :)
>>>> The method comment should probably highlight which definition is used.
>>>>
>>
>>
>> So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?
>
> 0 bytes, obviously.  The only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot.
>

Or from another POV, it's 4, the size of the slot. But we don't count
the size of the slots, they are already counted in the containing
object, that's why it should answer 0.


Thanks for the answers. I finally let this:

sizeInMemory
    "Answer the number of bytes consumed by this instance including object header."
    | isCompact headerBytes contentBytes |

    "SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot. From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0."
    (self isMemberOf: SmallInteger) ifTrue: [^0].

     contentBytes := self class instSize * Smalltalk wordSize. "inst vars"

     self class isVariable ifTrue:[ |bytesPerElement|
            bytesPerElement := self class isBytes ifTrue: [1] ifFalse: [4].
            contentBytes := contentBytes + (self basicSize * bytesPerElement)].

     isCompact := self class indexIfCompact > 0.
      headerBytes :=
                    contentBytes > 255
                        ifTrue: [ 3 * Smalltalk wordSize ]
                        ifFalse: [isCompact ifTrue: [Smalltalk wordSize] ifFalse: [2 * Smalltalk wordSize]].
            ^ headerBytes + contentBytes


Now I wonder...maybe instead of doing this it is easier to have a primitive that just calls #internalByteSize: ?
The problem of course is that it needs changes in the vm...

cheers

Mariano
 
isMemberOf: is so quaint...

Why not 
SmallInteger>>sizeInMemory
    "SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it.  
There is no SmallInteger object beyond the slot. 
From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0."
^0

and remove that part from the Object implementation.

Cheers,
Henry
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Mariano Martinez Peck
 


On Tue, Sep 28, 2010 at 11:11 AM, Henrik Johansen <[hidden email]> wrote:
 

On Sep 28, 2010, at 9:36 27AM, Mariano Martinez Peck wrote:



On Tue, Sep 28, 2010 at 6:46 AM, Nicolas Cellier <[hidden email]> wrote:

2010/9/27 Eliot Miranda <[hidden email]>:
>
>
>
> On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>
>>
>>
>>
>> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>>
>>>
>>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <[hidden email]> wrote:
>>>>
>>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:
>>>>
>>>> > Some notes:
>>>> >
>>>> > - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0?
>>>>
>>>> Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :)
>>>> The method comment should probably highlight which definition is used.
>>>>
>>
>>
>> So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?
>
> 0 bytes, obviously.  The only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot.
>

Or from another POV, it's 4, the size of the slot. But we don't count
the size of the slots, they are already counted in the containing
object, that's why it should answer 0.


Thanks for the answers. I finally let this:

sizeInMemory
    "Answer the number of bytes consumed by this instance including object header."
    | isCompact headerBytes contentBytes |

    "SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot. From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0."
    (self isMemberOf: SmallInteger) ifTrue: [^0].

     contentBytes := self class instSize * Smalltalk wordSize. "inst vars"

     self class isVariable ifTrue:[ |bytesPerElement|
            bytesPerElement := self class isBytes ifTrue: [1] ifFalse: [4].
            contentBytes := contentBytes + (self basicSize * bytesPerElement)].

     isCompact := self class indexIfCompact > 0.
      headerBytes :=
                    contentBytes > 255
                        ifTrue: [ 3 * Smalltalk wordSize ]
                        ifFalse: [isCompact ifTrue: [Smalltalk wordSize] ifFalse: [2 * Smalltalk wordSize]].
            ^ headerBytes + contentBytes


Now I wonder...maybe instead of doing this it is easier to have a primitive that just calls #internalByteSize: ?
The problem of course is that it needs changes in the vm...

cheers

Mariano
 
isMemberOf: is so quaint...

Why not 
SmallInteger>>sizeInMemory
    "SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it.  
There is no SmallInteger object beyond the slot. 
From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0."
^0

and remove that part from the Object implementation.


Uffff thanks Henrik for enlight me and teach me. Shame on me. I think that too much paper writting, ppt and admin tasks are killing me :(
But don't worry, now I will come to code again! Hope to recover... :)

 
Cheers,
Henry


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object?

Mariano Martinez Peck
 
Ok...I have just commited. If you want to review:

http://code.google.com/p/pharo/issues/detail?id=3032

cheers

Mariano

On Tue, Sep 28, 2010 at 1:45 PM, Mariano Martinez Peck <[hidden email]> wrote:


On Tue, Sep 28, 2010 at 11:11 AM, Henrik Johansen <[hidden email]> wrote:
 

On Sep 28, 2010, at 9:36 27AM, Mariano Martinez Peck wrote:



On Tue, Sep 28, 2010 at 6:46 AM, Nicolas Cellier <[hidden email]> wrote:

2010/9/27 Eliot Miranda <[hidden email]>:
>
>
>
> On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>
>>
>>
>>
>> On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck <[hidden email]> wrote:
>>>
>>>
>>> On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen <[hidden email]> wrote:
>>>>
>>>> On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote:
>>>>
>>>> > Some notes:
>>>> >
>>>> > - What should be answered for small ints? 1 sizeInMemory -->8. That's wrong. Shouldn't this answer 0?
>>>>
>>>> Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be "correct" answers in their own ways. 8 is definitely wrong though :)
>>>> The method comment should probably highlight which definition is used.
>>>>
>>
>>
>> So....what should we consider for SmallInteger ?   4 bytes or 0 bytes?
>
> 0 bytes, obviously.  The only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot.
>

Or from another POV, it's 4, the size of the slot. But we don't count
the size of the slots, they are already counted in the containing
object, that's why it should answer 0.


Thanks for the answers. I finally let this:

sizeInMemory
    "Answer the number of bytes consumed by this instance including object header."
    | isCompact headerBytes contentBytes |

    "SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it.  There is no SmallInteger object beyond the slot. From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0."
    (self isMemberOf: SmallInteger) ifTrue: [^0].

     contentBytes := self class instSize * Smalltalk wordSize. "inst vars"

     self class isVariable ifTrue:[ |bytesPerElement|
            bytesPerElement := self class isBytes ifTrue: [1] ifFalse: [4].
            contentBytes := contentBytes + (self basicSize * bytesPerElement)].

     isCompact := self class indexIfCompact > 0.
      headerBytes :=
                    contentBytes > 255
                        ifTrue: [ 3 * Smalltalk wordSize ]
                        ifFalse: [isCompact ifTrue: [Smalltalk wordSize] ifFalse: [2 * Smalltalk wordSize]].
            ^ headerBytes + contentBytes


Now I wonder...maybe instead of doing this it is easier to have a primitive that just calls #internalByteSize: ?
The problem of course is that it needs changes in the vm...

cheers

Mariano
 
isMemberOf: is so quaint...

Why not 
SmallInteger>>sizeInMemory
    "SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it.  
There is no SmallInteger object beyond the slot. 
From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0."
^0

and remove that part from the Object implementation.


Uffff thanks Henrik for enlight me and teach me. Shame on me. I think that too much paper writting, ppt and admin tasks are killing me :(
But don't worry, now I will come to code again! Hope to recover... :)

 
Cheers,
Henry