1

Here in the Main class that I defined the fields in two ways. The first case is serialized class inside a main that looks neat. This is especially good when a bunch of field are used in other classes that aren't polymorphic for some reason..

public class Main
{
    [Serializable]
    public class Tree
    {
        public float height;
        public int leavesCount;
        public Vector3 rootPosition;
    }

    private Tree tree = new Tree();
}

But I think we have another easy way to define them inside the main class like this we all ever do:

public class Main
{
    public float treeHeight;
    public int leavesCount;
    public Vector3 rootPosition;
}

the main question is, do code processing less pressure on the cpu in second way or not? Is this true or do I misunderstood the concept correctly? I hope you can help me.

public void GrowTree()
{
    tree.height += 1; // inside class definition..

    treeHeight += 1; // Does it have more performance?
}
Bill Hileman
  • 2,798
  • 2
  • 17
  • 24
KiynL
  • 4,097
  • 2
  • 16
  • 34
  • 2
    Paradigms such as object orientation, design patterns, multi-layered architectures, SOLID principles... do not always offer the best performance but they do allow the development of applications that would be impossible in the Main. You mat get better performance programming in assembler, but nobody makes their applications this way, it is neither maintainable nor profitable. Personally, unless the processor optimizations take over, I understand that Main will be faster but the improvement in time is negligible while the problems of this type of programming are huge. – Victor May 02 '22 at 22:22
  • Is it an option to make the `Tree` a [struct](https://stackoverflow.com/questions/30400876/is-serialization-possible-for-a-struct) instead of a class? – Theodor Zoulias May 02 '22 at 22:39
  • *Does it have more performance?* - how many nanoseconds do you need to save? – Caius Jard May 03 '22 at 05:02
  • @Victor Thank you sir. Of course it is, and thank you for your comprehensive answer. – KiynL May 03 '22 at 06:15
  • @TheodorZoulias struct can be lighter than a class. But changing its internal members sometimes encounters problems. – KiynL May 03 '22 at 06:16
  • @CaiusJard looll – KiynL May 03 '22 at 06:17
  • The point CaiusJard makes is a good one - you need to learn to *pick your battles* and realise that in *most circumstances* you'll be picking alternatives for reasons *other* than performance. If you have a performance *goal* that you have measured is not being met, *and* you've isolated it to this specific location, then just *try both alternatives* and see if either one will actually solve your problem. You *don't* achieve good performance by trying to identifying and enumerate millions of rules on the lines of "always do X rather than Y". – Damien_The_Unbeliever May 03 '22 at 12:33
  • @Damien_The_Unbeliever The first responds well to the expansion of large code, and the latter is sufficient for some small programs. Thank you for your comment – KiynL May 03 '22 at 13:51

1 Answers1

0

Yes, the second expression is more performant. Put it on a ludicrously hot path, and you will see significantly better execution times.

Any time you dereference a pointer to an instance of an object, you add complexity - e.g. offset calculation, address pointer copy, memory access - that costs a few CPU cycles. You can see IL and jitted asm for yourself in this sample at SharpLab. Even more so, if you access a struct (like Vector3) there are situations where the compiler will choose to create a defensive copy.

Also, the dereferenced pointer affects CPU caching which in itself could have an impact on performance. All in all, every time you write a . in C# there is a penalty. The same goes for accessing this or some other instance variable. But these penalties are miniscule.

l33t
  • 18,692
  • 16
  • 103
  • 180