Zastanawiałem się, kiedy za pomocą prostych zapytań jak, czy są jakieś różnice w wynikach:XPathSelectElement vs Potomkowie
var x = document.XPathSelectElement("actors/actor")
vs
var x = document.Descendants("actors").Descendants("actor")
pamiętać, że ta
var x = document.Elements("actors").Elements("actor").FirstOrDefault();
jest odpowiednikiem pierwszego rachunku.
Wystąpi różnica w wydajności, ponieważ metody robią bardzo różne rzeczy pod maską. Jednak optymalizacja operacji czysto w pamięci jest trochę bez sensu, chyba że masz do czynienia z dużym zbiorem danych. Jeśli masz do czynienia z dużym zbiorem danych, powinieneś zmierzyć wydajność obu opcji, zamiast próbować przewidzieć, który z nich będzie działał szybciej.
Ah, zgadza się. Dokładnie to, co musiałem wiedzieć. Dzięki! – Mattias
z wyjątkiem tego, że pracuje z dużymi plikami xml (jak 1gig lub większy) - wtedy mógłby chcieć zrobić test porównawczy (powinien sprawdzić, jak napisać poprawny mikrobenkmark: http://stackoverflow.com/questions/504103/how -do-i-write-a-correct-micro-benchmark-in-java) – user181750
@Christian: Czy istnieją dowody na to, że używanie XPathSelectElement ma "małą" różnicę w wydajności. Nie mówię, że to nieprawda, ale jak to jest znane. Jedynym sposobem, aby to było małe, jest to, że wynikowe wyrażenie XPath zostanie skompilowane i zapisane w pamięci podręcznej. Dotyczy to XPath w pliku System.Xml, ale czy jest taki sam w Linq-To-Xml? Czy istnieje jakiś dokument lub blog zespołu MS lub testy porównawcze zamieszczone w Internecie, które to potwierdzają? – AnthonyWJones
Tak, mimo że te dwie linie nie są równoważne.
XPath musi być analizowany ostatecznie do wyrażenia LINQ, które następnie to zrobić: -
var x = document.Elements("actors").Elements("actor");
Jednak jej całkiem możliwe, że wewnętrznie skompilowaną wersję wyrażenia XPath są przechowywane tak, że tylko przy użyciu XPath kosztuje czas potrzebny na wyszukanie napisu w wewnętrznym słowniku. Czy tak jest rzeczywiście, czy nie, nie wiem.
Interesujące czytanie. Dzięki! – Mattias
Wydaje się, że jest to hit, ktoś inny zrobił legwork analizy porównawcze: http://blog.dreamlabsolutions.com/post/2008/12/04/LINQ-to-XML-and-LINQ-to-XML-with-XPath-performance-review.aspx
Myślę, że benchmarking jest trochę wadliwy, ponieważ porównuje "//" wyrażenia XPath z dostępem do bezpośrednich potomków. –
Z mojego ograniczonego badania, wydajność wydaje się bardzo podobna. Wziąłem wiadomość próbka XML z http://msdn.microsoft.com/en-us/library/windows/desktop/ms762271(v=vs.85).aspx
XPath:
/book[id='bk109']
zapytań LINQ:
from bookElement in xmlElement.Descendants("book")
where bookElement.Attribute("id").Value == "bk109"
select bookElement
Następnie wykonywane są co 10.000 razy (z wyłączeniem czasu zajęło analizować ciąg i pierwszy uruchom, aby wyeliminować szum CLR).
Wyniki (100000 iteracje)
Wygląda więc na to, że przynajmniej w niektórych scenariuszach ocena XPath na XElement jest lepsza niż LINQ na XML. Oceny XPath na XPathDocument są jeszcze szybsze.
Ale wydaje się, że ładowanie XPathDocument trwa trochę dłużej niż ładowania XDocument (1000 iteracji):
'XPathDocument' powoduje bardzo duży ślad pamięci dla nietrywialnych dokumentów XML. –
Side UWAGA: odpowiedź na to pytanie ignorowanych http://stackoverflow.com/questions/3705020/what-is-the-difference-between- linq-to-xml-descendants-and-elements - drugie zapytanie zwróci węzły takie jak "/ foo/actors/random_nodes/actor", w przeciwieństwie do pierwszego, które zwraca tylko "actor", który jest bezpośrednim dzieckiem "aktorów". –