GOODBYE blog Park (with incomplete answer to the last QUIZ Section)

Hello, blogger!
The homepage is the place where excellent articles are published.
Your blog post "QUIZ: What is the size of an anonymous class with eight attributes ?" Removed from the homepage, which may cause you trouble. Please forgive me!
Homepage Article requirements: original, neatly formatted, the text clearly describes the topic of the article, the content is helpful to programmers.
The following types of articles cannot be sent to the homepage:

1) reprint; 2) only code;3) simple question; 4) software release; 5) Talent recruitment; 6) promotion or advertisement content; 7) activity information; 8) Commentary function disabled; 9) incomplete content.

 

Since bricks cannot be displayed on the home page, I don't want to quit. Sorry, it took so long in the blog park that I finally felt like I had exited from CSDN: it was impossible to justify the ethos here. C # is a self-written custom paging control a very valuable article? I do not mean that such an article is not good. Instead, it means that a short article that has aroused thinking has no value compared with this one. I don't know where the value of this article lies? In other words, there is not much nutrition in such a place, so we need to seriously consider another step.

 

I would like to ask some of you who think it is not worth putting on the homepage. How many of you can answer this question? How many of you have actually done this research? What does MetaData contain?Is this a simple question?

 

Some people on the WeChat blog said:

 

In fact, I don't think I can't write some non-technical things or create some topics. However, it is not the audience's decision. Some things that I don't think have a head-on view occupy the homepage, but some things that actually have a head-on view are instantly washed away by a large amount of hydrology. Well, I don't want to talk much about it. Finally, I will give the answer to QUIZ, Which is forcibly removed from the homepage.

 

An anonymous class containing eight attributes occupies approximately 5 kb of file storage space. That is to say, if you use 10 such anonymous classes, your file size will increase by about 50 kb. For a desktop application, 50 KB is nothing, but for a SilverLight application, this is not a small number. What's even more terrible is that if we don't know this problem, using an anonymous class with 42 properties, for example, will cause your file to grow by about 46KB. Of course, there is serious water, the reason will be briefly mentioned later.

Before starting some simple analysis, you may need to know some CLI knowledge, such as BlobHeap, UserStringHeap, StringHeap, and TableHeap, and the format used for assembly. Originally, I think that all of these users only need to use Google to search for CLI and MetaData, but now I think that, on average, this capability may not even be available. Well, here is the link. If you have the ability, please read it yourself:

Http://download.microsoft.com/download/d/c/1/dc1b219f-3b11-4a05-9da3-2d0f98b20917/partition%20ii%20metadata.doc

 

Next, let's take a simple analysis of this problem. To make the problem more obvious and prominent, we analyze a class with 42 attributes.

 

First, which parts of the entire Anonymous class will occupy a large amount of resources? According to statistics, TableHeap uses 5 k, StringHeap uses 7 k, Blob uses 27 k, UserString uses 1 k, and Body occupies nearly 5 k. It should be noted that, except for the relatively accurate Body part (IL code), the statistics of other parts are not accurate. This is because, according to the specifications, the same content is likely to be record by itself. The same content is used multiple times in the entire Assembly. For example, the attribute accessor name get_PageId may have this attribute in multiple classes; there are also many other reasons that may lead to repeated statistics. According to my estimation, a discount may be required. Even so, it will take about 14 K of space. To facilitate the discussion, we will ignore the repeated statistics here.

The Blog on the way occupies a lot of space. As for why, this is a part that I have not solved yet. It may be because:

1. BlobHeap contains many things, such as the signature of a function and the specific parameters used by tags;

2. There are many application scenarios, such as MethodRef, Method, and Param in TableHeap. Almost all tables may have pointers pointing to Blob. Even an IL in MethodBody, such as call System. Linq. Quearyable. Where '1..., may be added to Blob;

3. What we can see from Reflector cannot explain the cause of this increase in exceptions, or even exclude the Bug in the tool itself, which leads to a statistical error.

However, in any case, it is not explained by repeated statistics. The following two figures are given for illustration.

Aside from the strange Blob, there are also some problems that are easy to find. For example, why does an anonymous class need to use 1 K UserStringHeap? UserStringHeap records the string constants in your code, such as the following code:

Void Main ()
{
Console. WriteLine ("Hello world! ");

}

 

In such a statement, "Hello word! "Is to enter UserStringHeap, which occupies about 23 bytes. But how can we have a String constant in our anonymous class? It turns out that when the compiler generates an anonymous class, in order to facilitate debugging, it will put a DebuggerDisplayAttribute label in front of the class, for example: (to avoid leaking something, the field name has been modified, in the string... it indicates that there is still a long, long, long ......)

 

DebuggerDisplay (@ "\ {PageId = {PageId}, ReadId = {ReadId}, RefId = {RefId}, Guid = {Guid}, TypeId = {TypeId }, categoryId = {CategoryId}, Title = {Title}, Mode = {Mode}, Setting = {Setting}, Tags = {Tags }...} ", Type =" <Anonymous Type> ")]

 

 

The advantage of this label is that when you perform breakpoint debugging, you can see what attribute values are in this anonymous class. This tag causes UserString occupation. In different anonymous classes, the attribute names may be different. Even if they are the same, the order may be different. Therefore, the strings may not be exactly the same. Therefore, the more anonymous classes you use, the more unnecessary occupation. Fortunately, this problem only occurs in the compilation result of Debug, and this label is not available for Release of Release.

 

Next, you may be surprised that for an anonymous class with 42 properties, the StringHeap used will reach 7 k. Well, this is because of repeated statistics of my tools, which leads to excessive amplification. However, if you look at the Anonymous class carefully, you will find that:

1. An anonymous class with N attributes is actually a generic class with N generic parameters. Assume that one attribute is PageId:

2. the attribute name is PageId (7 bytes, note: The last character 0 in C string format)

3. The property accessors are get_PageId (11 bytes)

4. The member corresponding to the attribute is <PageId> I _ Field; (17 bytes)

5. the attribute's generic parameter name is <PageId> j _ TPar; (16 bytes)

6. The Anonymous class name is AnonymousType # 'n'. The number # indicates the # Anonymous class. The number N indicates that there are N attributes. For Anonymous class 1 with eight attributes, the length is 17 bytes. For anonymous Class 2 with 42 attributes, the length is 18 bytes;

7. Suppose the average length of our attribute names is exactly 6, so the anonymous classes of 42 attributes occupy at least 2 K.

 

From the above section, we can find that, if we optimize the Member names and generic parameter names that have almost no impact on normal operation, or even have little impact on reflection, to an average of 4 bytes (or even 0 bytes), you can reduce the space usage by more than half. For a dll with many anonymous classes, this part alone may be able to optimize the size of about 10 KB.

 

Another surprising thing is that MethodBody occupies a very large size of 5 K, with an average attribute containing more than 100 bytes. You need to know a property as follows:

Public int PageId
{
Get
{
Return _ pageId;
}

}

The corresponding il statement is as follows:

Ldarg.0
Ld1_thistype. _ pageId;
Ret

 

6 bytes in total. For Debug compilation, three additional statements are added to facilitate debugging, which is four more bytes. In other words, where are other functions? The functions of these functions are:

Equals, GetHashCode, ToString, and constructor.

 

 

If we use Reflector to open this function, we can see that Equals, GetHashCode, ToString, and constructors all need to access every attribute. This is almost inevitable for constructors, because each attribute of the anonymous class needs to be assigned a value. But why do we need to rewrite Equals and other three functions? This is because these objects may be used in the Dictionary Key. In this case, you must rewrite the Equals, GetHashCode, and ToString functions, the three functions add up to approximately 4 K. Accurately speaking, the total number of attributes of all anonymous classes determines the size of the Code in the entire dll. If there are 10 anonymous classes in your dll, each of which has about 10 attributes, the three functions occupy about 10 kb in size only in the Code section. Don't forget, in addition to code, we also need to write some metadata and a large number of userstrings. In fact, the probability of using these three functions is very small. It can be done through real-time dynamic Emit without occupying such a large space for code. Of course, dynamic generation of code also occupies a lot of space, but if you are working on a large project, for example, you have a lot of pages, each page uses different Dll, there are many anonymous classes in it, so the optimization cost is probably worth it. The other method may be better. It is assumed that the class will not be used as the Key for comparison, but as a common class, you can simply cut down the three methods (I haven't tried this method before, maybe you need to try it yourself ).

 

Finally, let's look at a strange problem about Blob, that is: the more attributes of an anonymous class, the larger the Blob that a certain attribute needs. For example, for an anonymous class with 42 properties, the Blob size used by an attribute accessor is shown in (including method signature, the method calls a function, the method signature used to use a MemberRef record generated by a member, and so on)

 

For an anonymous class with only eight attributes, the blob size used by an attribute accessor is:

 

At present, I think of a reasonable explanation that the field corresponding to this attribute needs to be returned, such as the following IL code:

Ldquo! 0 <> f_AnonymousType0 '42 <! <Xxx> j_TPar ,! <Xxx> j_TPar,... >:< PageId> I _ Field

Here, a signature for the Field <PageId> I _ Field is generated, and the signature contains various generic parameter information of the current class. Therefore, the more attributes, the more results Blob is occupied. As for whether the Blob in this part is like I guess, if so, whether each parameter will occupy so much or some of them will be reused, it is unknown. Of course, there may also be bugs in my program. I don't think I will continue to write in the blog garden.

 

If you are interested, you can download an open-source project called Mono. Cecil. My tool is based on this project. Through the source code of this project, you can have a good understanding of the structure of the entire. NET file. Of course, before you start reading this part of the code, you 'd better read the article I mentioned earlier, because the comments in this Mono. Cecil project are basically Zero. It is a huge challenge for those who never like to Read the fuck code.

 

Finally, I announced my official retirement from the blog Park. It's boring to complain too much about some things. Every release has a headache. Do you want to put it on the homepage or on the homepage? Then it would be a nightmare to select something I don't know from a bunch of green options that I don't know.

 

The key is, yes, I am very upset. You have moved out the small questions that I think are still difficult and challenging. You don't advocate thinking, and you are beginning to like topic creation. For those things that have no technical skills, the number of words is not too large. Isn't it still on the homepage? Since our outlook on life and values have already been divided, we have to part with them.

 

I just made a very difficult decision, that is, blog Park. I don't play anymore. As for whether you believe it or not, I believe it. Let's go. Go home. Bye, everybody!