Programmer's architectural design path (3): performance

In the previous blog's architectural design path (2), we set the architecture goal, namely maintainability. I did not mention performance at all. this was intentional.

In the previous blog's architectural design path (2), we set the architecture goal, namely maintainability. I did not mention performance at all. this was intentional.

It seems that programmers are all acute, maybe they are suffering enough time by the lengthy boot time of windows, maybe because the performance improvement is the most obvious ...... In short, I found that the attention and enthusiasm of most programmers for performance are unparalleled!

• C # Some people shook their heads and said, "Well, automatic garbage collection, isn't it good ?"

• DataSet was born, and many people were writing code right away, inserting millions of pieces of data into DataSet, proving the performance of DataSet.

• Of course, more should I be scolded for using Nima reflection? What is reflection, do you know? High performance! Not to mention those automatically generated SQL statements. is it highly efficient with my handwriting?

•......

So today, I still see that many programmers use stored procedures to build their systems without any regrets. a stored procedure can have thousands of rows! Then they asked innocently, "What is the use of the business layer? What exactly can we do ?"

When bringing a team, I am most afraid of performance-related issues. If you don't talk about performance, sometimes the code doesn't really look at it. if you emphasize performance, you don't know what kind of moth he will give you. In fact, this is a "degree" of mastery, so it is very difficult to express clearly in words. So after countless setbacks, I had to bite my teeth and say, "your code has only one criterion for judgment and maintainability. Performance issues are ignored first !" This answer does not seem to be public-especially for self-motivated programmers.

Therefore, I will talk about performance first, hoping to help you better understand this issue.

1. performance is not unimportant, but is not important for maintainability. To understand this, you must first understand the importance of maintainability (read the previous article and I spent weeks searching for bugs). then, you need to understand: solving performance problems, we can have a lot of effective methods out of the code, and the maintainability is basically only dependent on the code. Finally, remember: without sacrifice, there will be no victory!

2. Therefore, in most cases, when the performance conflicts with the maintainability, the performance lies in maintainability. We adopt other methods to make up for the problem of insufficient code performance.

Empty preaching is meaningless. Let's give an example!

Damage readability

Some time ago, when I review the code, I found that this programmer always uses First () instead of Single () after using Linq. I was surprised that according to the business logic, the returned value should be one, is it possible that there may be multiple, and multiple exceptions should be reported, so we should not take First () to complete the process? After thinking for a while, I asked this programmer his answer, which instantly gave me a sense of powerlessness. "First () has a higher performance !" The dialog recording is as follows:

"How do you know that First () has higher performance ?" I asked.

"First () Well, if we get the First qualified value, we will return and will not continue to query it. if Single () is used, we will keep checking and find all the data, and then take one of them."

"Are you sure? You know there is something called index ?"

"Ah ?......"

Then I told him that the index is a tree structure that can make queries faster.

"But I still think we should use First ()." After thinking for a while, he was still very firm.

"Why ?", I don't understand.

"Even if an index accelerates the query speed, it is faster to use First! Always faster, right ?"

"……", I really don't know what to say. In the end, a flash of light suddenly flashed. "Well, let's say, why does Microsoft develop a Single () method? Just to mislead you? Let the use of First () produce a sense of superiority, laugh at the use of Single ?"

He fell into meditation.

The comments are still entangled in Single ()/First (). please shout three times: readability! Readability !! Readability !!!

I found that the students are still entangled in this detail. Okay, let's explain it again:

1. how do you know that the database uses MSSQL? How do you know that it is a relational database? Isn't NoSQL good? So, how do you know how Single ()/First () is executed? For example, I want to write a Linq implementation to retrieve all the data, sort the data in the memory, and finally get the First one?

2. here we consider readability, which means that when you read the code, you can see Single () to instantly know that the coder means the only one; when you see First () the coder means the first one. It has nothing to do with the performance. if you need to tangle the performance, well: you need to determine the uniqueness, of course you need to check (including throwing an exception when the uniqueness is not exclusive), this performance loss should be appropriate; you need to take the first one. of course, sorting will also result in performance loss!

When I first entered the line, I also added several articles to my favorites, such as the top ten high-performance programming guidelines. the content in the articles is roughly as follows: "StringBuilder is always used, do not use '+'; always use ......, Do not use ......". In this type of articles, there are always a bunch of people, "Good !", "Thank you for sharing !" But slowly, I began to doubt these articles. until then, I realized why such a statement was superficial. only through the above conversation, only then can I clearly express my understanding.

All the simple encapsulation at the sacrifice of performance has a purpose. one of the important purposes is to improve readability. You deliberately do not use these off-the-shelf packages for performance. Generally, the loss is readability.

Take it for granted

Continue with the above example. At the very beginning, this programmer's consideration of performance was taken for granted. There are many situations that you may consider as follows:

Your understanding is totally wrong.

Your understanding cannot be an error, but the underlying layer has already optimized the problem.

My understanding is correct, and the underlying layer is not optimized.

1st and 2 are easy to understand. Why does 3rd say that he "takes it for granted? Because it is not in line with the hardware environment.

The simplest example is "cache ". For example, during the interview, I asked you a question: "Can the cache improve performance ?" Note that this is a trap. The answer should be: "Not necessarily ". Almost everyone believes that caching can quickly improve performance because the CPU and disk running speed of the computer is far behind the development of memory. Even so, uncontrolled caching can also drag the entire system down.

There are many similar examples. You are complacent. when I save a disk read/write operation, you increase the CPU load at the same time. you optimized the algorithm and reduced the CPU operation, but actually increased the memory pressure ...... There is no free lunch in the world. The same code, with the increase of data, hardware changes will present a completely different performance.

Therefore, in the development process, a lot of "optimization" is just what you take for granted. It is better to optimize the performance after obtaining the performance test results. At this time, I went back to what we said before. is the readability of the code more important? In this way, you can quickly find the bottleneck of this optimization! Otherwise, you will not be able to find any code that you can't understand.

Difficult to maintain

Another funny example is about myself. There is a function in a project: displays the blog body and provides a link to the next page of the previous page. The usual practice is to directly check in the database, but I always think it is wrong. is it necessary to perform two queries? Can it be optimized? So I came up with a "wonderful" idea: why don't I store the Id of the previous and next articles in my blog? So that I can get all the data in one round trip! Do you think I have a great idea?

This started with the nightmare.

First, we want to set the previous and next posts when posting a blog. However, what about the settings in the previous article and the next one? Not yet! When publishing a blog, you have to set the previous one and the later one.

Then, we have added a new feature. in addition to the previous and next posts, we also need to add the previous and next posts in the category of the current blog. What should I do? Add a field. Therefore, Previous, previusincategory, Next, and NextInCategory are available in the blog. At this time, it seems a bit inappropriate, but it is acceptable.

Next, there was a problem. The previous blog was deleted. what should I do? This process is equivalent to removing a node from a two-way linked list. The header is a little big.

In addition to publishing and deletion, the blog also has various other statuses, such as being blocked. After being blocked, whether or not it can be displayed is related to the current user. The current user is a common user and cannot be read. the current user is the author and can be read. What should I do? First, you need to set the previous one when blocking. when blocking is canceled, you still need to set the previous one. Then, the next article in the previous article had to be dumpfounded based on the changes of the current user ......

Finally, with tears, I changed all the code I 've been struggling with for a long time. I just checked it through the database. what a clear and concise logic is there! Performance problems? First, does this cause performance problems? Then, even if there is a problem, can I solve it with a cache?

Reasonable waste of heap hardware

Having said so much, I don't know whether it has aroused reflection from the students. Maybe you still don't have to worry about it: Obviously there is a way with higher performance, why don't we use it?

It's a waste!

What? Are you mistaken? My code saves at least one memory! That's why you haven't switched from the role of a poor student. You spent a week optimizing the code (without considering the increase in maintenance costs caused by your optimization), saving the boss a piece of memory. Do you think the boss will pat you on the shoulder to praise you? The boss cannot beat you!

Brother, the account is not yours. When you are a student, your time cost is 0, but when you enter the job, you will be paid every day.

Code-based high performance tuning is helpless-compromising hardware performance (see the hard work of game developers in 1980s. In this way, the write performance is high, but now no one writes the code like this ?). Otherwise, in most cases, the heap hardware is much better and cheaper than the optimized code. The cost of hardware is reduced by Moore's Law. can we reduce the wages of our programmers by Moore's law?

Clearly, window 10 is more performance-consuming than window 95. Why does no one use window 95 today? Why do we need 10 GB of space for VS 2013? Why do we use C # and no one uses assembly? We should naturally enjoy all these achievements as we stand in the accumulation of human civilization. You don't need a lighter. you need to get fire. If you want to learn how to survive, you can understand it. if you say that you are afraid of wasting natural gas, I ...... I ...... What do I say about you? "Is there a way to make a lighter ?" Similarly, if you are a programmer, you should write the underlying hardware path below as a good thing! Your code is 010001000010000001010101 ...... How do you let others live?

Finally, I suddenly think of one of the possible reasons why a programmer is so sensitive to performance and does not care about maintainability:

The performance is easy to understand, and the performance is slow and fast. The maintainability is hard to understand. at least two or three years of operation can be achieved. at that time, who knows where Ye was happy.

It's my fault that the programmer is ashamed to keep his head down. if there is a change in demand, the programmer will scold him, "which SB needs to be changed ......";

Do you think this is true? Therefore, few people are willing to refine the code into steel. It is an inexplicable sorrow and sorrow.

Finally, there are some famous sayings that I can think of for your reference:

Premature optimization is the source of all evil

To optimize the performance, you must first find the performance bottleneck ". Otherwise, anyone can click "optimize this code"

Code with better readability is always better optimized

Hardware is always cheaper than software