Nối tiếp XML chậm

Question

Tôi đã kế thừa một dự án trong đó mô hình dữ liệu của ứng dụng là một tài liệu XML. Các nhà phát triển trước khi tôi đã tạo ra một mô hình đối tượng dựa trên lược đồ xml này, và sau đó được mã hóa dựa vào mô hình đối tượng.

Sau nhiều năm bảo trì, ứng dụng này đã dần dần bắt đầu hiển thị tuổi của nó. Trưởng nhóm đã nói rằng lý do chính đằng sau điều này là do sự chậm trễ của xml serialization. Tôi rất muốn gọi BS về vấn đề này, nhưng nhiều tệp xml mà chúng tôi xử lý có kích thước trên 2MB và lưu ý những điều cơ bản về những gì diễn ra đằng sau hậu trường với các đối tượng được đánh dấu là [Serializable], 2MB rất nhiều để phản ánh do đó có thể có một số sự thật với lý thuyết chậm chạp.

Theo kinh nghiệm của bạn, việc tuần tự hóa có thực sự 'chậm'/xấu để chọn tham gia mô hình XML -> XPath thay vì mô hình XML -> POCO không?

BTW đây là dự án .NET 2.0 và khách hàng của chúng tôi có thể sẽ nâng cấp lên .NET 3.5 vào cuối năm tới.

Answer 1

Nói chung, không, tôi không nghĩ sự chậm lại là do việc sắp xếp XML; 2MB không phải là lớn, và nó không nên gây ra bất kỳ sự suy giảm lớn.

Điều tôi muốn quan tâm hơn là trưởng nhóm cho bạn biết sự chậm lại là gì do không cung cấp cho bạn bất kỳ thông tin hồ sơ cụ thể nào HIỂN THỊ bạn rằng đó là trường hợp. Ý kiến ​​về tối ưu hóa thường xuyên sai; hồ sơ tồn tại cho mục đích tìm chính xác nơi mà bất kỳ sự chậm lại đang xảy ra trong một ứng dụng. Tôi muốn khuyên bạn nên thiết bị và lập hồ sơ ứng dụng và tìm nơi chậm lại; Tôi muốn đặt cược nó không phải trong XML serialization.

Answer 2

Xml serialization không sử dụng thuộc tính Serializable. Trình serializer xml thực sự tạo ra một assembly để ánh xạ xml với đối tượng, nó không sử dụng sự phản chiếu. Đây là một trong những lý do Xml Serialization chỉ hoạt động với công chúng.

Một điều bạn có thể thử là đo lường bằng cách sử dụng DataContractSerializer là một phần của WCF. Thật thú vị khi thấy sự khác biệt.

Tôi chưa bao giờ gặp phải giới hạn hiệu suất cá nhân nhưng tôi cũng không có các đối tượng lớn như mô tả của bạn. Một điều cần lưu ý là một hàm tạo mà bạn sử dụng để tạo ra XmlSerializer, một số chúng không lưu trữ bộ nhớ được tạo ra và sẽ dẫn đến mất hiệu năng và rò rỉ bộ nhớ vì mỗi cuộc gọi sẽ tạo ra nhiều hội đồng hơn và nhiều hơn nữa . Nếu trường hợp này xảy ra, bạn có hai tùy chọn:

1) Bộ nhớ cache của trình tạo trình tự nối tiếp bạn đã tạo. Tôi tin rằng đó là chủ đề an toàn nhưng bạn sẽ muốn kiểm tra lại MSDN.
2) Người dùng một hàm tạo khác nhau để tạo XmlSerializer.

Answer 3

Chạy trình thu thập thông tin và xem phần lớn thời gian CPU đang được sử dụng. Cho dù nó trở thành serialization XML hay ở một nơi khác, bạn sẽ biết nơi để tập trung nỗ lực của bạn. Ngoài ra, đối với hồ sơ, tôi đã thấy xê-ri hóa XML đang chậm đáng ngạc nhiên trong quá khứ trong thế giới Java khi làm việc với Spring RPC. Vì vậy, nó chắc chắn có thể sếp của bạn là đúng, nhưng thay vì đoán, bạn nên kiểm tra.

Answer 4

Vì nó chưa được đề cập ở đây, tôi nghĩ rằng tôi muốn chỉ ra rằng có một tùy chọn trong VS để tạo ra các hội đồng tuần tự hóa XML tại thời gian xây dựng.

http://msdn.microsoft.com/en-us/library/kb4wyys2(v=VS.100).aspx

Bạn cũng có thể sử dụng sgen.exe bằng tay để làm thế hệ nếu bạn muốn kiểm soát nhiều hạt mịn.

Điều này cắt giảm thời gian cần thiết để sắp xếp một loại vì, như JoshBerke đã nói ở trên, XmlSerialiser tạo ra một lắp ráp mới bất cứ khi nào cần serislise hoặc deserialise, có thể mất thời gian cho các loại phức tạp. Tạo trước các hội đồng tuần tự hóa của bạn do đó có thể dẫn đến những cải thiện hiệu suất đáng kể.