Performance comparison of array sorting methods (1): Precautions and tests

Yesterday, a friend wrote an article comparing the list<t> sort method with the performance of the sorting method in LINQ, and the result was that "the Linq sort method performs better than List<t>." Sort method. This result makes me very puzzled. Because List<t> The Sort method changes the order of elements inside the container, and the LINQ sort gets a new sequence. If the two sorting algorithms are exactly the same, and the LINQ sort is more expensive than the other element replication, why is the performance higher? If the algorithm/implementation of LINQ sorting is better, then why. NET FX does not list<t>. Sort also optimize it? So today I have done a simple experiment on this problem.

Attention matters

In the comments that follow, someone said, List<t>. Sort is "inner sort," and the LINQ sort is "external sort." But according to the definition of an external sort, this argument is not correct. "External sort" refers to the size of the target is too large, causing main memory is relatively small (such as memory) and not enough, have to use external storage (such as hard disk) to do some "transition" sort. Therefore, the LINQ sort generates a new sequence, but it is also an internal sort. In fact, it is also easy to infer from the definition that, if the data is of the same size, the performance of the external sort is generally worse than the internal sort-but we are not very good at doing it, because if it is possible to do an internal sort, who will use the external sort of trouble?

The result in that article is wrong, so what is the problem? In my opinion, the problem is mainly in the following two points.

First, the original author used asp.net as the test environment. It is worth noting that the ASP. NET executes. NET code, it uses the CLR that is hosted in the IIS process, and it is configured and run directly. NET applications (different CLR managed configurations are likely to be different-for example, the CLR hosted in SQL Server). For example, ASP. NET, the call stack for each thread is 250K and runs directly. NET application, this size is 1M. Based on my experience (that is, I can't exactly "prove" this), the results of performing such a performance test in asp.net may be very unstable. Therefore, I generally recommend that you use one of the most common console applications for performance testing.

Second, and more importantly, the original has only tested the performance of a single order. This is a big taboo in performance testing, because the error is too great. For example, if you are testing a method, you suddenly have a background process in place to maintain it, using a portion of CPU and memory resources, which can lead to an increase in the time spent in testing. And. NET program has a "warm-up" process, which causes the code to have a raw code in the first execution of the process (commonly known as "warm-up"). This process is not related to the execution efficiency of the code, as it will only produce one consumption at a time, and the code will be executed countless times. Therefore, in the test, it is important to repeat the test target n times, at least to allow execution time to reach the "second" level, such results have a certain reference value. If the execution time is too small, the test may not be accurate-know that the "timer" is also a cost, but also error, we need to get as accurate as possible results.

Finally, I strongly recommend using Codetimer for timing, because in its initialize method, the current process and the thread priority are set to the highest, thus reducing the interference caused by other extraneous factors. If you can, you should also try to shut down other applications or services in your system, and it is best to disconnect the network (which is one reason). Of course, release compilation is also necessary. Also, if you must use ASP.net for performance testing, remember to set the Debug attribute of the <compilation/> node to false--in Web.config, taking into account that the original author ignored the obvious taboo, I strongly suspect that this is not enough. :)

Therefore, I think the test result in that article is inaccurate, the reference value is very low.