Class自动属性的内存分配

Question

I have a class with multiple properties. For example

public class Customer
    {
        public int id { get; set; }
        public string abc{ get; set; }
        public bool abcd { get; set; }
        public string abcde { get; set; }
        public string abcdef { get; set; }
        public string abcdefg { get; set; }
        public string abcdefgh { get; set; }
        public string xyz { get; set; }     
    }

Now I want to know how much memory space is consumed by the get set properties. I only require few of the properties in one of my API call and all of these properties for another API call. So I want to know whether I should create two different classes and use them for my separate API calls or just use one common class with multiple get set properties and use it for my API calls. Any guidance will be much appreciated. Thanks

Answer 1

the int and bool will typically be packed together into 8 bytes; the string references take 4 (32-bit) or 8 (64-bits) for the references. If the strings have non-null values , then that space will be allocated separately and will be whatever the string needs.

But frankly: unless you're allocating millions of them, splitting it into 2 different types won't save you anything real - it will just be yak shaving. Especially for the scenario where the strings are null .

Answer 2

We have to exclude the string. This one can be anywhere from "null" to "whatever Max Lenght for string was today".

Theoretically a Autoimplement Property should cost as much as a minimal, manual property: One backing field. One get and one set function for the entire type. The single most important rule about properties is to not accidentally access the backing field in class code. And Autoimplement Properties do that, by simply not giving the Backing Field a name you could use. It is still there. It propably has a name derived from the Property name for Reflection. But your code has no realy way to access it.

Theoreitically, because now coems in the JiT. The JiT can do a lot of Optimisations:

• Those Automatic accessors are very little code. So there is a decent chance that the cost of Inlining them is below the cost of calling them. So I give it a 90% chance the JiT will inline those.
• If you create a temporary variable to use it the next line, this one might run into DeadCode detection. Wich means it will be cut out and replaced by the originall access.
• But of coruse it goes the other way too. In order to get around the overhead inherent in ArrayBounds Checks, the JiT might detect "redundant Acesses" with teh same Index and create a temporary variable to use.

While I have not read about it yet, I would not rule out that the JiT can even cut unused properties from classes. It is all just runtime optimisations. It at least can cut unaccessed varriables (and their initialsiation) out as dead code. As I found out when I tried forcing a 2 GiB OOM:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace OOM_32_forced
{
    class Program
    {
        static void Main(string[] args)
        {
            //each short is 2 byte big, Int32.MaxValue is 2^31.
            //So this will require a bit above 2^32 byte, or 2 GiB
            short[] Array = new short[Int32.MaxValue];

            /*need to actually access that array
            Otherwise JIT compiler and optimisations will just skip
            the array definition and creation */
            foreach (short value in Array)
                Console.WriteLine(value);
        }
    }
}

I agree that this is Micro Optimisations. But even more, those might be ones the JiT can do for you already . So you might save nothing at all. Personally I prefer read- and debugability of code way before such Optimisations. I can often do something "ineffective" because I can rest in the knowledge the JiT will propably deal with it.