Производительность Linq to XML - автономный тест против очень большого веб-приложения - PullRequest
0 голосов
/ 29 июня 2009

Итак, я выбрал определенную горячую точку из очень большого веб-приложения, которое выполняет большую часть обработки XML (добавление узлов, добавление атрибутов к узлам на основе некоторой логики), а затем создал автономный тест для имитации той же ситуации, используя Linq to XML (в отличие от XmlDocument)

В автономном тесте производительность увеличилась в 2-10 раз по сравнению Linq To Xml с использованием XmlDocument.

Теперь такое же изменение было применено к веб-приложению, но улучшение не проявилось ни для производительности, ни для памяти - вообще, оно оказалось почти таким же, как при использовании XmlDocument . Все остальные факторы / код были одинаковыми до и после, поэтому было сделано все, чтобы никаких других изменений не было.

Помимо параллелизма - веб-запросов, я не уверен, почему это произойдет.

Любые предложения будут оценены. Кто-нибудь еще сталкивался с подобным поведением?

[Тесты проводились в Windows XP и Windows Server 2003 с .Net framework 3.5]

Обновление : Также я должен упомянуть, что здесь нет дискового ввода-вывода. XML создается на лету в памяти и не записывается обратно в файл или что-либо еще. Он используется только для возможности перехода на другую внешнюю систему, которая ожидает этого. Внешняя система остается неизменной до и после.

Ответы [ 2 ]

1 голос
/ 29 июня 2009

Вам нужно сравнить яблоки с яблоками.

  • Не сравнивайте Web + XmlDoc с StandAlone + LinqXml.
  • Сравните StandAlone + XmlDoc с StandAlone + LinqXml.
0 голосов
/ 29 июня 2009

Я полагаю, что доступ к диску является основным узким местом для подхода веб-сервера, и поэтому любые преимущества в способе анализа XML перекрываются доступом к диску. Однако это предположение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...