Chúng ta nên ghi nhớ hiệu suất khi viết mã đồng thời tránh thực hiện tối ưu hóa nano. Đôi khi những gì trông giống như tối ưu hóa tiết kiệm lại tạo ra sự khác biệt lớn. Hôm nay chúng ta sẽ xem System.Text.Json có một cái bẫy hình phạt hiệu suất như thế nào.

Có gì sai với mã này?

Mỗi khi chúng ta chạy chức năng này, nó sẽ tạo một JsonSerializerOptions mới. Nó tệ đến mức nào khi khởi tạo một đối tượng mới mỗi lần? Nói chung, việc tạo một đối tượng mới mỗi lần là không đáng kể về hiệu suất và cấp phát bộ nhớ. Tuy nhiên, trong khi thực hiện hồ sơ hiệu suất, nhóm của tôi đã nhận được kết quả đáng ngờ. Thời gian thực hiện các chức năng đó là như nhau:

• SendToServiceBus()
• Tuần tự hóa ()

Tại sao Serialize lại chậm như vậy?

System.Text.Json mới sử dụng tham chiếu phiên bản của JsonSerializerOptions để lưu trữ siêu dữ liệu tuần tự hóa vào bộ đệm, vì vậy nếu bạn cung cấp một phiên bản mới mỗi lần, bạn sẽ mất bộ nhớ đệm và mã phải thực hiện thao tác tạo siêu dữ liệu cho từng chức năng tốn kém gọi.

Vấn đề phổ biến đến mức Microsoft thậm chí còn có cả một trang dành riêng cho vấn đề này.

Thí dụ

Các tài liệu cung cấp ví dụ điểm chuẩn này:

Như bạn có thể thấy từ các tài liệu, sự khác biệt là rất lớn, đắt hơn 200 lần. Và không có bất cứ điều gì sẽ cho bạn biết về nó, không có ngoại lệ hay cảnh báo. Cách duy nhất bạn sẽ tìm thấy điều này là trong quá trình kiểm tra tải và lập hồ sơ. Tôi tự hỏi liệu đây có phải là một cảnh báo hay không, vì vậy chúng tôi sẽ giảm số lần mắc lỗi này.

Phần kết luận

Các phương pháp hay như biết vòng đời của các đối tượng và tối ưu hóa việc tạo cho các đối tượng đơn lẻ có thể mang lại nhiều lợi ích hơn so với hình thức của chúng. Vì vậy, tôi khuyên bạn nên tìm hiểu khi bạn muốn một Singleton hoặc một đối tượng mới theo yêu cầu.

Hãy nhớ rằng việc tạo các tùy chọn bộ nối tiếp mỗi lần có ý nghĩa quan trọng vì khung lưu trữ siêu dữ liệu nội bộ dựa trên tham chiếu SerializerOptions.

Nếu bạn thấy một JsonSerializerOptions() mới, hãy đảm bảo rằng nó ở dạng Singleton.

Chúc mừng mã hóa.