Linq2Xml. Сложность алгоритма.
От: Кэр  
Дата: 16.07.10 17:12
Оценка:
Джентельмены,

Вот этот алгоритм заменяет все вхождения CData тэга на текстовую ноду с encoded XML символами:

foreach (var xcData in rootElement.DescendantNodes().OfType<XCData>().ToArray())
{
    xcData.ReplaceWith(new XText(xcData.Value));
}


И от простоты этого кода я тащусь как удав по стекловате. Но я не очень в курсе деталей реализации Linq2Xml — так что мне интересно, как будет вычитываться и обновляться XML документ в данном случае (XmlReader или DOM модель). Сколько проходов по документу будет сделано и сколько памяти придется использовать для обработки.
Re: Linq2Xml. Сложность алгоритма.
От: Lloyd Россия  
Дата: 16.07.10 17:15
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>И от простоты этого кода я тащусь как удав по стекловате. Но я не очень в курсе деталей реализации Linq2Xml — так что мне интересно, как будет вычитываться и обновляться XML документ в данном случае (XmlReader или DOM модель).


DOM, конечно. Точнее аналог.

Кэр>Сколько проходов по документу будет сделано и сколько памяти придется использовать для обработки.


Вроде как оин.
Re[2]: Linq2Xml. Сложность алгоритма.
От: Кэр  
Дата: 16.07.10 17:25
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>DOM, конечно. Точнее аналог.


Т.е. по запросу ничего не подтягивается? Когда я делаю
XDocument doc = XDocument.Load(filePath);

сразу парсится весь документ до последнего элемента, ноды и аттрибута?
Re[3]: Linq2Xml. Сложность алгоритма.
От: Lloyd Россия  
Дата: 16.07.10 17:57
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Т.е. по запросу ничего не подтягивается? Когда я делаю

Кэр>
XDocument doc = XDocument.Load(filePath);

Кэр>сразу парсится весь документ до последнего элемента, ноды и аттрибута?

Ну да.
Re[4]: Linq2Xml. Сложность алгоритма.
От: Кэр  
Дата: 16.07.10 20:38
Оценка:
Здравствуйте, Lloyd, Вы писали:

Кэр>>сразу парсится весь документ до последнего элемента, ноды и аттрибута?

L>Ну да.

Хм, спасибо Я почему-то думал, что он разбивает XML на блоки-объекты по мере надобности. Но не сильно представлял как такое работает в общем случае

В таком случае все понятно. Аналог DOM модели это, конечно, довольно грустно. Зато для среднего размера документов работает просто прелестно.
Re[5]: Linq2Xml. Сложность алгоритма.
От: Lloyd Россия  
Дата: 16.07.10 21:33
Оценка:
Здравствуйте, Кэр, Вы писали:

Кэр>Хм, спасибо Я почему-то думал, что он разбивает XML на блоки-объекты по мере надобности. Но не сильно представлял как такое работает в общем случае


Кэр>В таком случае все понятно. Аналог DOM модели это, конечно, довольно грустно. Зато для среднего размера документов работает просто прелестно.


Ну в общем это просто замена XmlDocument.
Re[6]: Linq2Xml. Сложность алгоритма.
От: Кэр  
Дата: 17.07.10 02:21
Оценка: 5 (1)
Здравствуйте, Lloyd, Вы писали:

L>Ну в общем это просто замена XmlDocument.


Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ. Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.
Re[7]: Linq2Xml. Сложность алгоритма.
От: _FRED_ Черногория
Дата: 17.07.10 07:54
Оценка:
Здравствуйте, Кэр, Вы писали:

L>>Ну в общем это просто замена XmlDocument.


Кэр>Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ. Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.


XPathDocument уже есть.
Help will always be given at Hogwarts to those who ask for it.
Re[7]: Linq2Xml. Сложность алгоритма.
От: Lloyd Россия  
Дата: 17.07.10 14:22
Оценка:
Здравствуйте, Кэр, Вы писали:

L>>Ну в общем это просто замена XmlDocument.


Кэр>Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ.


И в чем смысл такого аналога? Чуть расширить область применения XDocument-а (из-за меньшей потребности в памяти)?

Кэр>Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.


Парсить все равно придется, единственно на чем можно будет сэкономить — это на меньшей потребности в памяти.
Re[8]: Linq2Xml. Сложность алгоритма.
От: Кэр  
Дата: 18.07.10 14:15
Оценка:
Здравствуйте, _FRED_, Вы писали:

Кэр>>Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ. Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.


_FR>XPathDocument уже есть.


Хочется (наверное) чтобы при этом LINQ был еще под рукой. Скажем, чтобы вот такой примерно запрос можно было использовать без загрузки всего документа в память — а только по требованию:
foreach (var xcData in rootElement.DescendantNodes().OfType<XCData>().ToArray())
Re[8]: Linq2Xml. Сложность алгоритма.
От: Кэр  
Дата: 18.07.10 14:17
Оценка:
Здравствуйте, Lloyd, Вы писали:

Кэр>>Вообще интересно, насколько полезен был бы read-only аналог Linq2Xml, который не пытается парсить весь документ.


L>И в чем смысл такого аналога? Чуть расширить область применения XDocument-а (из-за меньшей потребности в памяти)?


Ага. Только для экстремальных случаев. Скажем нужно вычитать гигабайтную XML.

Кэр>>Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.


L>Парсить все равно придется, единственно на чем можно будет сэкономить — это на меньшей потребности в памяти.


Ожидается, что возможно не придется парсить все — а только то, что необходимо. А меньшая потребность в памяти — это собственно главная цель.
Re[9]: Linq2Xml. Сложность алгоритма.
От: Lloyd Россия  
Дата: 18.07.10 14:50
Оценка:
Здравствуйте, Кэр, Вы писали:

L>>И в чем смысл такого аналога? Чуть расширить область применения XDocument-а (из-за меньшей потребности в памяти)?


Кэр>Ага. Только для экстремальных случаев. Скажем нужно вычитать гигабайтную XML.


Ну это будет все равно временная отсрочка летального исхода, т.к. у того же XmlDocuemnt-а, если мне не изменяет память размер занимаемой памяти был где-то в 3 раза больше, чем исходного xml-я. Т.е. даже в экстремальных случах кардинально это проблему не решит.

Кэр>>>Только те куски, которые необходимы для выполнения данной xml query. Не нужны аттрибуты — они и не парсятся — просто хранятся в сырой строке данного XML элемента. Или вообще все XML поддерево — не запросили деталей из него, ну и не надо пока парсить. Сохранить просто как контент XML элемента. По запросу — можно вытащить.


L>>Парсить все равно придется, единственно на чем можно будет сэкономить — это на меньшей потребности в памяти.


Кэр>Ожидается, что возможно не придется парсить все — а только то, что необходимо.


Как ты себе это представляешь? Уже для того, чтобы загрузить xml, его надо проверить на валидность, а для этого его придется пропарсить.

Кэр>А меньшая потребность в памяти — это собственно главная цель.


Для этого есть XmlReader.
Re[10]: Linq2Xml. Сложность алгоритма.
От: Кэр  
Дата: 18.07.10 15:28
Оценка:
Здравствуйте, Lloyd, Вы писали:

Кэр>>А меньшая потребность в памяти — это собственно главная цель.


L>Для этого есть XmlReader.


Ну собственно я и предлагаю сделать XmlReader на стероидах. Сделать провайдер Linq, который умеет работать поверх XmlReader или его аналоге. Точнее просто рассуждаю тут вслух.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.