Shulou(Shulou.com)06/03 Report--

This article mainly shows you the "sample analysis of .net coding and design principles", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and learn the article "sample analysis of .net coding and design principles".

Vs-like structure

Instances of the class are allocated on the heap and accessed through a reference to the pointer. Passing these objects is inexpensive because it is just a copy of a pointer (4 or 8 directly). However, objects also have some fixed overhead: 8 or 16 bytes (32 or 64-bit systems). These overhead include pointers to the method table and synchronization fields for other purposes. However, if you look at the memory occupied by an empty object through the debugging tool, you will find that it is 13 or 24 bytes larger (32-bit or 64-bit systems). This is caused by the memory alignment mechanism of .NET.

On the other hand, the structure has no overhead above, and its memory usage is a combination of field sizes. If the structure is a local variable declared in a method (function), it allocates controls on the stack. If the structure is declared as part of the class, the memory used by the structure is part of the memory layout of the class (so it is allocated on the heap). But when you pass the structure to the method (function), it will copy the byte data. Because it is not on the heap, the structure does not cause garbage collection.

So there's a compromise. You can find all kinds of suggestions about the size of the structure, but I won't tell you an exact number here. In most cases, your structures need to keep a small size, especially when they need to be passed frequently, and you need to make sure that the size of the structure does not cause too much problem. The only thing that is certain is that you need to analyze it according to your own application scenario.

In some cases, the difference in efficiency is quite large. When an object doesn't seem to have a lot of overhead, you can see the difference between an object array and a structure array. In a 32-bit system, suppose a data structure contains 16 bytes of data, and the array length is 100w.

Use the space occupied by an array of objects

8-byte array overhead +

(4-byte pointer address X1000000) +

((8 byte header + 16 bytes of data) X1000000)

= 28MB

Use the space occupied by the structure array

8-byte array overhead +

(16 bytes of data X1000100)

= 16MB

If you use a 64-bit system, the object array uses 40MB, while the structure array is still 16MB.

As you can see, in a structured array, data of the same size takes up less memory. As the number of objects in the object array increases, it also increases the pressure on GC.

Besides space, there is also the problem of CPU efficiency. CPU has a multi-level cache. The closer the CPU is, the smaller the cache is, but the faster the access is, and the easier it is to optimize sequentially saved data.

For an array of structures, they all have continuous values in memory. It is easy to access the data in the structure array, and you can get the corresponding value as long as you find the correct location. This means that there is a huge difference in iterative access to large array data. If the value is already in the CPU's tell cache, its access speed is an order of magnitude faster than accessing RAM.

If you want to access an item in an array of objects, you need to get a pointer reference to the object first, and then access it in the heap. Iterating over the object array will cause the data pointer to jump in the heap and update the CPU cache frequently, thus wasting a lot of opportunities to access the CPU cache data.

In many cases, by improving the location of data stored in memory, reducing the overhead of CPU accessing memory is one of the main reasons for using structures, which can significantly improve performance.

Because structures are always copied when they are used, be careful when coding, or you will generate some interesting bug. For example, the following chestnut, you cannot compile:

Struct Point {public int x; public int y;} public static void Main () {List points = new List (); points.Add (new Point () {x = 1, y = 2}); points [0] .x = 3;}

The problem is that in the last line, you try to change a value of the Point element in the list, which is not possible because points [0] returns a copy of the original value. The correct way to modify the value is

Point p = points [0]; p.x = 3 position points [0] = p

However, you can adopt a stricter coding strategy: do not modify the structure. Once the structure is created, never change its value. This eliminates the above compilation problems and simplifies the rules for using structures.

As I mentioned earlier, structures should be kept small, avoiding spending a lot of time copying them, but occasionally using large structures. For example, an object with the details of the final business process needs to hold a large number of timestamps:

Class Order {public DateTime ReceivedTime {get; set;} public DateTime AcknowledgeTime {get; set;} public DateTime ProcessBeginTime {get; set;} public DateTime WarehouseReceiveTime {get; set;} public DateTime WarehouseRunnerReceiveTime {get; set;} public DateTime WarehouseRunnerCompletionTime {get; set;} public DateTime PackingBeginTime {get; set;} public DateTime PackingEndTime {get; set;} public DateTime LabelPrintTime {get; set;} public DateTime CarrierNotifyTime {get; set;} public DateTime ProcessEndTime {get Set;} public DateTime EmailSentToCustomerTime {get; set;} public DateTime CarrerPickupTime {get; set;} / / lots of other data...}

To simplify the code, we can divide the time data into our own substructures so that we can access the Order object in this way:

Order order = new Order (); Order.Times.ReceivedTime = DateTime.UtcNow

We can put all the data in our own class:

Class OrderTimes {public DateTime ReceivedTime {get; set;} public DateTime AcknowledgeTime {get; set;} public DateTime ProcessBeginTime {get; set;} public DateTime WarehouseReceiveTime {get; set;} public DateTime WarehouseRunnerReceiveTime {get; set;} public DateTime WarehouseRunnerCompletionTime {get; set;} public DateTime PackingBeginTime {get; set;} public DateTime PackingEndTime {get; set;} public DateTime LabelPrintTime {get; set } public DateTime CarrierNotifyTime {get; set;} public DateTime ProcessEndTime {get; set;} public DateTime EmailSentToCustomerTime {get; set;} public DateTime CarrerPickupTime {get; set;}} class Order {public OrderTimes Times;}

However, this introduces an additional 12 or 24 bytes of overhead for each Order object. If you need to pass the OrderTimes object as a whole into various method functions, this may make some sense, but why not pass the Order object into the method? If you have thousands of Order objects at the same time, it may result in more garbage collection, which is caused by additional references to the objects.

Instead, changing the OrderTime to a structure and accessing the individual properties of the OrderTImes structure through properties on the Order (for example: Order.Times.ReceivedTime) does not result in a copy of the structure (.NET optimizes this access). So the OrderTimes structure is basically part of the memory layout of the Order class, almost as much as there are no child constructs, and you have more beautiful code.

This technique does violate the immutable structure principle, but the trick here is to treat the fields of the OrderTimes structure as fields of the Order object. You don't need to pass the OrderTimes structure as an entity, it's just a code organization.

The above is all the content of the article "sample Analysis of. Net coding and Design principles". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.