Mã trong hàm dựng tĩnh chạy chậm hơn

Question

Tôi nhận thấy rằng thời gian khởi động sẽ khác nhau tùy thuộc vào tại đây tôi đã đặt một đoạn mã khởi tạo. Tôi nghĩ điều này thật kỳ lạ, vì vậy tôi đã viết một điểm chuẩn nhỏ, điều này đã khẳng định những nghi ngờ của tôi. Có vẻ như mã được thực thi trước khi phương thức main được gọi chậm hơn bình thường.

Tại sao Benchmark(); chạy ở các tốc độ khác nhau tùy thuộc vào việc được gọi trước và sau đường dẫn mã thông thường?

Đây là mã chuẩn:

class Program { 
    static Stopwatch stopwatch = new Stopwatch(); 
    static Program program = new Program(); 

    static void Main() { 
     Console.WriteLine("main method:"); 
     Benchmark(); 
     Console.WriteLine(); 

     new Program(); 
    } 

    static Program() { 
     Console.WriteLine("static constructor:"); 
     Benchmark(); 
     Console.WriteLine(); 
    } 

    public Program() { 
     Console.WriteLine("public constructor:"); 
     Benchmark(); 
     Console.WriteLine(); 
    } 

    static void Benchmark() { 
     for (int t = 0; t < 5; t++) { 
      stopwatch.Reset(); 
      stopwatch.Start(); 
      for (int i = 0; i < 1000000; i++) 
       IsPrime(2 * i + 1); 
      stopwatch.Stop(); 
      Console.WriteLine(stopwatch.ElapsedMilliseconds + " ms"); 
     } 
    } 

    static Boolean IsPrime(int x) { 
     if ((x & 1) == 0) 
      return x == 2; 
     if (x < 2) 
      return false; 
     for (int i = 3, s = (int)Math.Sqrt(x); i <= s; i += 2) 
      if (x % i == 0) 
       return false; 
     return true; 
    } 
} 

Kết quả cho thấy Benchmark() chạy gần gấp đôi chậm cho cả các nhà xây dựng tĩnh và constructor cho static Program program tài sản:

// static Program program = new Program() 
public constructor: 
894 ms 
895 ms 
887 ms 
884 ms 
883 ms 

static constructor: 
880 ms 
872 ms 
876 ms 
876 ms 
872 ms 

main method: 
426 ms 
428 ms 
426 ms 
426 ms 
426 ms 

// new Program() in Main() 
public constructor: 
426 ms 
427 ms 
426 ms 
426 ms 
426 ms 

Tăng gấp đôi số lần lặp trong vòng lặp chuẩn gây ra tất cả các lần tăng gấp đôi, cho thấy rằng hình phạt hiệu suất phát sinh không phải là hằng số, mà là một yếu tố.

// static Program program = new Program() 
public constructor: 
2039 ms 
2024 ms 
2020 ms 
2019 ms 
2013 ms 

static constructor: 
2019 ms 
2028 ms 
2019 ms 
2021 ms 
2020 ms 

main method: 
1120 ms 
1120 ms 
1119 ms 
1120 ms 
1120 ms 

// new Program() in Main() 
public constructor: 
1120 ms 
1128 ms 
1124 ms 
1120 ms 
1122 ms 

Tại sao điều này xảy ra? Nó sẽ có ý nghĩa nếu khởi tạo sẽ chỉ là nhanh nếu nó được thực hiện nơi nó thuộc về. Thử nghiệm đã được thực hiện trong .NET 4, chế độ phát hành, tối ưu hóa trên.

Answer 1

Đây là một vấn đề rất thú vị. Tôi đã dành thời gian thử nghiệm với các biến thể của chương trình của bạn. Dưới đây là một vài quan sát:

1. Nếu bạn di chuyển phương thức tĩnh Benchmark() vào một lớp khác, hình phạt hiệu suất cho hàm tạo tĩnh biến mất.

2. Nếu bạn đặt phương thức Benchmark() thành phương pháp thể hiện, hình phạt hiệu suất sẽ biến mất.

3. Khi tôi lập hồ sơ các trường hợp nhanh (1, 2) và các trường hợp chậm (3, 4), các trường hợp chậm sẽ tốn thêm thời gian trong các phương thức trợ giúp CLR, cụ thể là JIT_GetSharedNonGCStaticBase_Helper.

Dựa trên thông tin này, tôi có thể suy đoán về những gì đang diễn ra. CLR cần đảm bảo rằng mọi hàm tạo tĩnh thực hiện tối đa một lần. Một biến chứng là các nhà xây dựng tĩnh có thể tạo thành một chu kỳ (ví dụ, nếu lớp A chứa một trường tĩnh kiểu B và lớp B chứa một trường tĩnh kiểu A).

Khi thực thi bên trong một hàm tạo tĩnh, trình biên dịch JIT chèn kiểm tra xung quanh một số lời gọi phương thức tĩnh để ngăn chặn các chu kỳ vô hạn tiềm năng do phụ thuộc lớp tuần hoàn. Khi phương thức tĩnh được gọi từ bên ngoài của một hàm tạo tĩnh, CLR biên dịch lại phương thức để loại bỏ các kiểm tra.

Điều này sẽ khá gần với những gì đang diễn ra.

Answer 2

Đây là một sự kiện được ghi nhận rất tốt.

Trình xây dựng tĩnh chậm. Thời gian chạy .net không đủ thông minh để tối ưu hóa chúng.

tham khảo: Performance penalty of static constructors

constructor tĩnh rõ ràng là tốn kém vì họ yêu cầu mà bộ thực thi để bảo đảm rằng giá trị được đặt chính xác trước khi bất kỳ thành viên của lớp được truy cập. Chi phí chính xác là phụ thuộc vào kịch bản, nhưng nó có thể khá đáng chú ý trong một số trường hợp.