Разбираем FB2 - DOM, SAX, VTD.

Достоинства и недостатки каждой разборки (парсинга), кто что скажет?

С сайта http://vtd-xml.sourceforge.net/
Конечно они больше себя хвалят, но лично я с ними согласен.

Comparison with DOM, SAX and PULL

Processing Model Description
VTD: In memory cursor based on "non-extractive" VTD records (Virtual Token Descriptor)
DOM: In memory object model based on Node object and "extractive" tokens
SAX/PULL: Low-level tokenizer based on "extractive" tokens

Performance
VTD: Fastest (outperform SAX with Null Content handler)
DOM: Slowest
SAX/PULL: Second fastest, Raw speed un-indicative of its real world performance

Memory Usage
VTD: 1.3x ~1.5x of the document size
DOM: 5x~10x of the document size
SAX/PULL: Doesn't grow with document size

Random Access
VTD: Yes
DOM: Yes
SAX/PULL: No, Forward only

Usability
VTD: Excellent (shortest code for most given tasks)
DOM: Very good
SAX/PULL: Poor

Incremental Modification
VTD: Yes
DOM: No
SAX/PULL: No

Inherent Persistence (avoid parsing every time)
VTD: Yes
DOM: No
SAX/PULL: No

Hardware Implementation
VTD: Yes
DOM: N/A
SAX/PULL: N/A

Спасибо. Это я вчера прочитал Very Happy

Интересуют взгляды с точки зрения практики. Теоретически, похоже, VTD вне конкуренции. Я пользовал DOM, сделав оболочку для FB2 в Delphi на встроенный парсер, который сам являлся оболочкой для MSXML. Разбирать удобно, с размерами памяти и скоростью согласен, но мне это было не критично. Критично для ридела. Практически (еще не вник) можно ли на его основе сделать ридер под mobile windows (Pocket PC)?

На мой взгляд - сравнение по скорости некорректное. Они сравнивают сканирование. А для нужд библиотеки нужно сравнивать две части: первичное сканирование для создания книжки в памяти + беготня по книжке. И если для первой части - порядок возможно верный, то для второй, например, SAX просто не годится. А DOM и VTD - думаю, будут примерно равны по скорости (но DOM - часто или удобнее, или единственно возможным, они сами это подтверждают, там что-то типа "для сложных запросов все-равно вам придется использовать DOM")

Также нужно сравнить по памяти. DOM - делает полную структуру в памяти, причем иерархическую. Это даже не столь большой overprint, сколько просто файл бывает большой. Например, что делать, если файл мегабайтов пять? Для десктопа все-равно, это-то да. А для КПК?

VTD - также предполагает, насколько я понял, хранение самого файла в памяти + некая структура для ускорения доступа к частям файла. То есть тот же DOM, вид сбоку. С измененными приоритетами скорости доступа. В DOM - доступ ко всем веткам одинаково (среднебыстрый, например), а с VTD - к некоторым быстрее, к некоторым медленнее.

SAX и StAX - опять же, применябельны только для чтения. После чего они обязаны создать что-то в памяти для дальнейшего чтения книжки. Хотя я, наверное, могу себе представить двунаправленный ридер, который читает непосредственно из файла и рисует странички.

Ридер для PocketPC можно сделать и там и там и там. Поэтому нужно понять, чем можно пожертвовать, а что лучше уменьшить. И по каким-то критериям выбирать.

Admin
Оперативка 64 мегабайта - забивается очень и очень быстро. И резидентами и "многозадачностью". У меня после запуска системы, загрузке PIM'а и пары нужных приложений (аська, иногда скайп) для читалки остается около 4-5 метров. Это на Acer N311, далеко не самом старом КПК.

Так что память - пока еще критичная вещь. Для КПК - тоже. На мой взгляд это учитывать стоит.

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