Class Footprint

1

I would think the answer to this question would be the same regardless if we were talking about Xojo, Swift, Java etc.

Scenario
the code for an app defines a CLASS (call it FOO). This class contains some properties unique to each instance, and 1000’s of lines of code to manipulate those properties.

Now (taking a re-engineering effort out of the equation)… If I had 1000 instances of FOO what kind of footprint is consumed?

  1. 1 x (size of code) + 1000 x (size of properties + a bit of overhead)
  2. 1000 x ((size of code) + (size of properties) + (overhead)
  3. something else
2
  1. Size of (binary) code is only relevant to the class. Instances use methods on a shared base and forward their handle to it. You can use ObjectiveC Runtime to read instance sizes. It’s usually not much.
1 Like
3

#1 in any sane world. The code isn’t different per instance so all should share the same code. I’m not aware of an environment where this wouldn’t be the case.

4

Thanks… that is what I figured .

I have a class called “FakeControl”, which manifests itself as an image of ANY (macOS or iOS) control… therefore it has 57 unique routines used to “draw” these. It is easier to have those functions private to the class than to make them their own entity.

5

While it’s generally a good idea to keep particular units of code small, it is just form for form’s sake sometimes to split code up. I have a lot of code and even pretty long methods occasionally, but the code is logically where it belongs and is only used in one place and highly unlikely to be used elsewhere in the future. If ever I’m wrong about that, it isn’t that onerous to refactor it then, but it hasn’t happened in this code base in 15 years.

For example if you need to apply a lot of conditional tests and formatting of text, it’s hard to break it down into smaller methods because the names of these smaller methods logically can’t be anything but SmallerMethod1 … SmallerMethodN or maybe StripTrailingDetrius(n) with conditionals or a jump table inside … it just moves the pain around, it doesn’t really alleviate it. The things have to be done in a certain order, but they are the same class of things.

1 Like
6

I was thinking about your situation and lack of dynamism in Swift.

I assume you’ve decided not to subclass for a reason, because if you did subclass, that would avoid the need for a long switch / select.

7

That’s what I was thinking too. In an own GUI editor test (macOS only, declare-enhanced pure Xojo), I found it much easier to subclass “layoutControl” accordingly and such have a direct connection to the native control class. Otherwise branching became much too long to have a good oversight.
Translation into/from original class can be done with a dictionary which works much faster retrieving the entries as a nice side effect.

1 Like
8

For Xojo for example the cost would be 28 bytes + size of properties per instance of the class. (Size of code does not scale with number of instances)

For C++ it is size of properties per instance of the class.

For Swift…I do not really know but given how it works I would imagine there might be small overhead like in Xojo but dont know for sure.

1 Like
9

I know its not what you were asking, but you can get the memory bytes of you class like this in Swift.

class MyClass {
    
    var description: String
    let version: Float = 1.0
    
    init() {
        self.description = "MyClass Version : \(version)"
    }
    
}

let myClass = MyClass()
print("myClass Description = \(myClass.description)")

let myClassSize = class_getInstanceSize(type(of: myClass))
print("myClass Size = \(myClassSize)")

You could maybe experiment with basic custom classes, with properties of known data type sizes, and check the memory footprint with different class types, using the ‘class_getInstanceSize()’ function.

Regards Mark

10

Thanks… based on that each instance is between 800 and 1100 bytes…