Data structure and algorithm series (1) Time Test

Objective

For a long time the data structure and algorithm of things forgotten, recently want to revisit this knowledge. So I wrote a series of << data structure and algorithms, I hope to study together with you to explore this knowledge. I hope everyone will point out different.

1. Time Test

Because this part uses a practical method to analyze the data structure and algorithm detection, so avoids the use of the Big O analysis here, but uses the method which runs the simple benchmark test to replace. This test will show how many seconds (or whatever time unit) it takes to run a piece of code.

Benchmark testing is a time-testing method to measure the length of time spent running the full algorithm. As with science, benchmarking is an art, and it requires careful testing of code in order to get accurate analysis. Here's a detailed discussion.

1.1 A simplified time test

First time testing requires one of these codes. For the sake of simplicity, this will test a subroutine for the contents of the console array. The code looks like this:

1://Set up an array

2:static void Buildarray (int[] arr)

3: {

4:for (int i = 0; I <= 99999; i++)

5: {

6:arr[i] = i;

7:}

8:}

9:

10://Output array

11:static void Displaynums (int[] arr)

12: {

13:for (int i = 0; I <= arr. GetUpperBound (0); i++)

14: {

15:console.writeline (Arr[i] + "");

16:}

17:}

To test this subroutine, you need to create one that is, and the system time assigned to this variable when the program is called. In addition, a variable is needed to store the time when the subroutine returns. The following code is written based on these elements:

DateTime StartTime;

TimeSpan Endtime;

StartTime = DateTime.Now; Endtime = DateTime.Now.Subtract (starttime);

My machine configuration: CPU 1.9GHz four cores, 4G memory, Win7 flagship version, when running the code, subroutine running time about 30 seconds (29.94). Although this code seems to be quite reasonable for the execution time test, it's in. NET environment, the runtime code is completely unsuitable. Why, then?

First, the code measures the time that is lost between the start of the subroutine call and the return of the main program to the subroutine. However, the time measured by the test also includes the time spent with other processes that were run concurrently with the C # program.

Second, the time code is not considered. NET environment, the garbage collection is performed in the In the type. NET, the system may pause at any time that a garbage collection is performed. Time code instances do not take into account the garbage collection time and the resulting time that is easily affected by garbage collection. So what exactly should be done?