bugGNU Octave - Bugs: bug #55810, sizeof() and whos() returns 0...

 
 

bug #55810: sizeof() and whos() returns 0 bytes for classdef objects

Submitted by:  Andrew Janke <apjanke>
Submitted on:  Sat 02 Mar 2019 01:27:48 PM UTC  
 
Category:  Octave Function Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 05 Mar 2019 07:29:08 PM UTC, comment #8: 

Ack that. Trying again with 'datetime' in the Matlab online tool

>> x = datetime(zeros(100, 3));
>> size(x)
ans = 1×2

    100     1

>> s = whos('x'); s.bytes
ans = 801

So yeah, it does look like the 'bytes' size of classdef objects defined in m files reflects the sum of the sizes of its properties.

Mike Miller <mtmiller>
Project Administrator
Tue 05 Mar 2019 02:17:12 AM UTC, comment #7: 

I think the Matlab employee responding there is incorrect, at least in terms of user-defined Matlab objects (classdef objects). I have posted a reply there.

`containers.Map` is probably not a good example to use for this, because it is a special builtin class implemented in the Matlab runtime itself, not as a classdef object implemented in M-code. Try a @datetime, @duration, or @table object instead; those are implemented as classdefs.

Andrew Janke <apjanke>
Sun 03 Mar 2019 09:44:33 PM UTC, comment #6: 

Since 'sizeof' is not a defined Matlab function or object method, it's intentionally not used as an override when getting the size of objects in 'whos'.

I tested with 'containers.Map' in the Matlab online feature, and the size of the map object is 8 bytes, regardless of how many entries are added to the map.

I found this: https://www.mathworks.com/matlabcentral/answers/14837-how-to-get-size-of-an-object

Where a Mathworks employee wrote

> Unfortunately, there is no way to check the amount of memory that is being
> occupied by class objects, since MATLAB is storing references to C++
> objects. As you say, whos is representing the size of the pointer to the
> created object, which will be 60 bytes (in 32-bit) or 112 bytes (in 64-bit).
>
> However, you can create a function in your class and calculate the real
> memory of the object by manually querying for the memory of each of the
> properties in the class, like you do with whos for a matrix.


So I think we can choose to return whatever we want to for 'whos' and 'sizeof' on class objects, since there is no compatibility problem here.

Mike Miller <mtmiller>
Project Administrator
Sun 03 Mar 2019 04:51:09 AM UTC, comment #5: 

I don't see how running code that you have written would violate a non-compete clause.  Also, depending on your jurisdiction, non-competel clauses may not be generally enforceable, as is the case in California.  If The Mathworks is too vigorous in attempting to suppress alternatives it is also vulnerable to being fined for anti-competitive behavior.

But, for the purposes of this bug report.  If there is no particular behavior that we are trying to match we may as well just leave it as is.

Rik <rik5>
Project Administrator
Sat 02 Mar 2019 10:21:18 PM UTC, comment #4: 

Sorry, I'm leery of running any tests on Matlab, for fear of violating the Matlab license's non-compete clause.

Andrew Janke <apjanke>
Sat 02 Mar 2019 06:15:41 PM UTC, comment #3: 

For reference, can you check how Matlab handles an instance of MyDumbClass?

Bumping the release to dev, and changing the OS to Any.

Rik <rik5>
Project Administrator
Sat 02 Mar 2019 01:39:29 PM UTC, comment #2: 

Oh. Also, for complex objects, counting the total number of raw bytes in their object/memory graph could be a complex, expensive operation because you have to traverse a lot of objects. So maybe the default behavior of sizeof() and the Bytes column in whos() should be to return/show NaN and '?', respectively, to avoid causing them to hang in casual usage.

Andrew Janke <apjanke>
Sat 02 Mar 2019 01:30:38 PM UTC, comment #1: 

Oh, whoops: looks like `whos` does not respect `sizeof` overrides. If I add a custom sizeof to MyDumbClass:

classdef MyDumbClass

  properties
    data
  endproperties

  methods
    function this = MyDumbClass (data)
      this.data = data;
    endfunction

    function out = sizeof (this)
      out = sizeof (this.data);
    endfunction
  endmethods

endclassdef

Then sizeof() reports a big number, but whos() still shows 0 bytes.

>> sizeof(x)
ans =  8000000
>> whos
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        ans         1x1                          8  double
        x           1x1                          0  MyDumbClass

Total is 2 elements using 8 bytes

Maybe whos() should delegate to sizeof(), respecting overrides?

Andrew Janke <apjanke>
Sat 02 Mar 2019 01:27:48 PM UTC, original submission:  

It looks like the default implementation of sizeof() returns 0 for user-defined classdef objects. (I think this also causes the Bytes for classdef objects in the `whos` output to be displayed as 0.)

IMHO, it would make more sense for the default implementation of sizeof() to  do a `builtin('struct', x)` on user-defined objects and return that. That would give you a decent approximation of the Octave-managed raw data being used by those objects.

To reproduce:

Define MyDumbClass.m:

classdef MyDumbClass

  properties
    data
  endproperties

  methods
    function this = MyDumbClass (data)
      this.data = data;
    endfunction
  endmethods

endclassdef

Create one and check its size:

>> x = MyDumbClass(zeros(1000, 1000))
x =
<object MyDumbClass>

>> sizeof(x)
ans = 0
>> sizeof(x.data)
ans =  8000000

I think that sizeof(x) should be returning 8000000 instead of 0.

Andrew Janke <apjanke>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by apjanke (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-11 mtmiller Severity2 - Minor => 1 - Wish
        Item GroupInaccurate Result => Feature Request
        Summarysizeof() returns 0 for classdef objects => sizeof() and whos() returns 0 bytes for classdef objects
    2019-03-11 mtmiller Dependencies- => bugs #46652 is dependent
    2019-03-03 mtmiller Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 3 - Low
    2019-03-02 rik5 Item GroupIncorrect Result => Inaccurate Result
        StatusNone => Confirmed
        Release4.4.1 => dev
        Operating SystemMac OS => Any

    Back to the top


    Powered by Savane 3.5