Có phải dấu vết ngăn xếp của hàm đã được giữ nguyên trên một ngoại lệ được ném không?

Question

Khi biên dịch tệp thi hành ở chế độ Chế độ phát hành với bật tối ưu hóa mã - trình biên dịch có thể chọn các hàm nội tuyến đáp ứng các tiêu chí nhất định để cải thiện hiệu suất.

Câu hỏi của tôi là: khi ngoại lệ được ném vào phần thân của hàm được gạch chân, thông tin stacktrace có được giữ nguyên bất kể mở rộng nội tuyến không? Nói cách khác, nó sẽ hiển thị chức năng gốc là nguồn lỗi, hay nó sẽ hiển thị chức năng gọi thay thế?

Answer 1

Nó phụ thuộc vào cách ngoại lệ được ném. Nếu bạn sử dụng câu lệnh ném thì bạn không gặp sự cố, trình kích hoạt sẽ không nội tuyến có chứa cú ném. Một cái gì đó để được nhận thức khi bạn cần một setter tài sản được btw nhanh.

Tuy nhiên, nếu ngoại lệ là do thực thi bình thường, như NullReferenceException hoặc IndexOutOfRangeException v.v ... thì có, bạn không thấy tên của phương thức trên dấu vết ngăn xếp nếu nó được gạch chân. Điều này có thể hơi hoang mang nhưng bạn thường tìm ra từ mã nguồn của phương thức gọi và kiểu ngoại lệ. Hy vọng nó tương đối nhỏ. Thuộc tính [MethodImpl(MethodImplOptions.NoInlining)] có sẵn để chặn nội tuyến. Khi bạn phát hiện ra nó sẽ hữu ích, nó thường là quá muộn;)

Answer 2

Đây không phải là một câu trả lời dứt khoát nhưng tôi đã cố gắng để trang trí một phương pháp đơn giản mà chỉ thực hiện phép chia cho không với [MethodImpl(MethodImplOptions.AggressiveInlining)] thuộc tính đó trong .NET 4.5 đưa ra một gợi ý để các JIT (mà thực sự thực hiện nội tuyến) nội tuyến một phương pháp nhất định và khi tôi chạy chương trình trong chế độ phát hành, ngoại lệ được báo cáo từ phương thức gọi, không phải là phương thức có phép chia. Mặt khác, như Hans đã nói, phương pháp với các câu lệnh ném và logic luồng phức tạp không được gạch chân. This Article trên blog MSDN (mặc dù từ năm 2004) cung cấp cho bạn tổng quan về cách nội tuyến được thực hiện bởi JIT.