C # and C, C , D, Java performance comparison (2)
(Article from http://mag.vchelp.net) jason
Recurrence. The percentage is calculated by the algorithm shown by Listing5. For each language, we will do 10,000 computing, taking into account the Java stack is easily exhausted when the deep place is still exhausted, so each operation is limited to 4,500 recursive.
Sieve. The rigid number is obtained by the iterative algorithm shown by Listing 6 Each language is implemented with its iteration is 10,000,000.
Strcat. String Connection --- is usually the root cause of a large number of runtime overhead, and it is also a potential field that leads to the efficiency of the program. (I have done a sensitive project that is sensitive to performance. I have achieved 10% overall performance improvement by improving the efficiency. Testing four different types of variables: Short, int, double and a string Then, connect them into a String variable to be completed, and add a segmentation segmentation when connecting. Four different connectors when connecting
Method: 1) Default Connection Method 2) Expected Low Connection Method 3) C language typical printf / format format, need to reassign space 4) For improved performance, see Listing7
STRSWTCH. String comparison by cascading Switch. Compares by language support or through some columns of IF-ELSE statement simulation (Listing 8). This test is to verify whether the C # string processing function is as efficient as he claims. The test is divided into two parts: first is the assignment between the strings, that is, the same identity (the translator Note: The pointer inside the string is directly copied, and the copy of the string content is not involved). Secondly, it is compared by the copy of the string, which avoids the same identity comparison but the literal comparison between the strings. 850000 superlocks were performed on each language because the Java VM memory was exhausted after more than this number.
STRTOK string segmentation. Strings are also very low, sometimes evenly caused serious operation overhead. This test (LISTING 9) reads the entire contents of a text file to a string, then remove the section. The first variable is separated by a character separator: ';' Separate strings and ignores all blank. The second variable is also separated by a semicolon, but retains a blank. The third and fourth variables are skewers: <->, and ignore and retain the blank. Only the second variable in c uses strTok (), C four variables with STLSoft's String_Tokeniser template, but each correctly assigns a value to the parameter. C # first variable with system.String.Split (), 2 to 4 variable synsoft.text.tokeniser.tokenise (); java with java.util.StringTokenizer, only supports variables 2 and 4 (Note: I choose Stlsoft) String_tokeniser Template is not I want to promote Stlsoft, but the test indicates that it is 2.5 times faster than Boost, and Boost is the first choice when most developers are looking for libraries).
result
In the NOOP test, Table 2 lists an average overhead that loads an empty operation in microseconds (US). Obviously, the difference between C, C , D is logical, and each is about 5-6 milliseconds, and Intel is determined to 2 ms. The only thing I think may be that this compiler optimizes the initialization of all C real-time runners. If this is the case, this performance cannot be reflected in other non-experiments, because it requires at least some C ..., which needs to be in-depth research. C # used approximately 70ms, Java about 0.2 seconds. C # and Java loading clearly shows that it is actually overhead in their real-time running structural basis (VM and Support DLLS). However, in addition to the commercial batch of large-scale command lines, the basic construction of the extremely large system (30,000 code) or CGI, launching overhead is not important in most cases. The heavy-in server allows to start within a few seconds, so 200ms in the language room is slightly micro.
The remaining results are shown in three parts. Figures 2 and 3 show a result of string connection and segmentation, respectively. Figure 1 contains the remaining test results, let's take a look at it now.
In Fig. 1, the results of each test item, C, C, C , D, and Java are displayed in the percentage of its corresponding test item C # runtime. Therefore, the results of 100% line down fluctuations are quite comparable to C # performance. High percentage shows that C # performance is excellent, and low percentage indicates that C # performance is relatively poor.
