이제이 유형의 질문 (특히 this - 두 개체에 대한 설명이 매우 적절하다고 생각합니다.)이 여기에있었습니다. 제 질문은 성능에 관한 것입니다. XML 문서의 크기가 100 - 300K 이상인 XML 문서가 여러 개 있습니다. 나는이 정보를 XmlDocument 객체가 아닌 XDocument으로로드 할 때 약간의 지연이 있음을 발견했습니다. 이 두 객체간에 심각한 성능 차이가 있습니까? 그들은 XML의 내용에 다르게 접근합니까? 선호되는 XML 문자열로 작업하거나 차이점이 있습니다. 이 개체의 최종 용도는 해당 개체에 대한 쿼리 (XPath 또는 LINQ)를 실행하는 것입니다.성능 : XDocument 대 XmlDocument
이 역시 메모리와 속도와 관련하여 주로 성능 문제입니다.
XmlDocument는 순수하게 관리되는 문서 개체 모델의 구현입니다. MSXML 라이브러리와 같은 COM 구성 요소와의 interop은 없습니다. 그렇지 않으면 어떤 주장도 완전히 가짜입니다. XLinq 전체 API 세트는 .NET Framework에서 LINQ를 도입하여 XML과 상호 작용하는 친숙한 방식으로 등장했습니다.
성능을 최대화하고 XPath 사용에 익숙한 사용자는 XmlDocument를 사용하고 compiled XPath expressions을 사용해보십시오.
XmlReader은 .NET의 모든 다른 XML API가 장면에서 사용하는 .NET에서 가장 낮은 API입니다. 당연히 이는 처리가 가장 어렵고 빠름을 의미합니다. 스트리밍 API이기 때문에 메모리에도 가장 적합합니다. LINQ to XML을 일명 XmlDocument 및 XDocument 사이
, 여기에 몇 가지 원료 번호는 다음과 같습니다 https://www.altamiracorp.com/blog/employee-posts/performance-linq-to-sql-vs는 http://blogs.msdn.com/b/codejunkie/archive/2008/10/08/xmldocument-vs-xelement-performance.aspx
는 둘 다 XDocument 클래스는보다 효율적인/빠른 것을 찾을 수 있습니다. 프로그래머의 생산성/효율성도 무시해서는 안됩니다. 개인적으로는 XDocument으로 더 쉽게 작업 할 수 있습니다.
그리고 LINQ는 마술처럼 성능을 향상시키지 않습니다. 또한 LINQ의 목표는 프로그래머 생산성을 높이는 것입니다. 프로그래머의 생산성을 높이는 것입니다. 프로그래머 생산성을 높이는 것입니다. 개발자가 이미 LINQ를 알고 있고 프레임 워크에서 제공하는 "오래된"XML API를 모른다면 그럴 수 있습니다. –