Вот возникла проблема в выборе xml-парсера для считывания файлов подсветки.

В самой первой версии (1.0 которая), использовался xml-парсер, написанный собственноручно.
Но минусами такого подхода были:
- нагромождение кода в компоненте;
- неудобность (сравнительно) добавления новых тегов в формат файла;
- не полная поддержка стандарта xml (например, кодировки).

Поэтому в версии 1.8 (текущая) было принято решение использовать сторонний xml-парсер TXmlParser.
Плюсы:
- код компонента изрядно разгрузился;
- работать с файлом подсветки стало проще;
- более полная поддержка стандарта xml (UTF-8, ISO-8859-1, Windows-1252).
Минусы:
- это всё-таки сторонний компонент (но легко встраивается);
- компонент перестал обновляться два года назад.

Совсем недавно Quadr0 предпринял попытку переписать компонент с использованием стандартного делфийского парсера TXmlDocument.
Плюсами являются:
- полная поддержка стандарта xml;
- вроде бы более простое использование;
- возможность сохранения;
- обновляемость компонента вместе с Delphi.
Минусы:
- класс создаёт DOM-объект (минус?);
- парсер вроде бы считается медленным (?).

Вопрос: Как Вы думаете, какой xml-парсер лучше предпочесть для компонента и почему?

Это сообщение отредактировал(а) Vitalik - 25.7.2005, 17:12

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 00:49

Цитата(Quadr0 @ 24.7.2005, 01:03)

Тетсты показали, что подсветки с переписанным парсёром грузятся также быстро, как и с тем что был раньше. Однако, стоит заметить, что в новой версии компонента было добавлено много новых тэгов для реализации новых возможностей (каких? увидите сами), вследствие чего, обрабатывать нужно больший объём информации. Получается, что скорость работы TXMLDocuement всё же выше, чем у TXMLParser.

Позволь с тобой не согласиться!
Подсветки с парсёром TXmlDocument грузятся также быстро, потому, что в новом формате все теги ключевых слов объединены в один. То есть не надо каждое из тысячи ключевых слов загружать по отдельности. (Замечу, что реально заметить скорость работы парсера в обоих случаях можно только на больших файлах, а значит, с большим количеством ключевых слов)
А тегов для новых возможностей не на столько больше, чем было количество тегов ключевых слов. А именно: их несравнимо меньше!
Поэтому, ИМХО, скорость работы у TXmlDocument никак не выше, чем у TXmlParser.

Цитата(Quadr0 @ 24.7.2005, 01:03)

Причём, с гарантией того, что всё сделано правильно. В прошлой версии процедура сохранения писалась сама. Т.е. TXMLParser для этого никак приспособлен не был. Приходилось вручную обрабатывать каждую тэгу и зверски нагромождать код. И никто не мог гарантировать, что могла допуститься ошибка, которая приведёт к тому, что файл подсветки перестанент быть xml совместимым. Теперь о нагромождениях и опасениях за формат можно забыть.

А это немного спорный вопрос. Несомненным преимуществом прошлого способа была возможность разместить содержимое xml-файла так, чтобы в случае необходимости его можно было удобно просматривать вручную (как текстовый файл)
Замечу, что часть пользователей компонента принципиально не использует дизайнер, поэтому красивость xml-файла это немаловажный показатель.

P.S. Я пока никак не проголосовал.

Вопрос в скорости.
Медленная загрузка никому не нужна, тогда компонент просто перестанут использовать

Я бы сгенерил 10 xml-файлов (по полмега) и сравнил скорости 2х парсеров.
Если одинаковые - то TXmlDocument без сомнений - как намного более удобный для разработчика.
Иначе TXmlParser

А TXmlDocument, кстати, действительно довольно удобен в обращении!
Загружаешь xml из файла/потока одной процедурой и потом работаешь с xml-документом просто как с деревом
Удобно!

Я даже начал склоняться ко второму варианту...

На сорсах в разделе Дельфи s-mike (у него кстати можно и у нас спросить) месяца 3-4 назад делал сравнительный обзор парсеров и сравнение их скоростей работы. Парсер от MS (тот который в Дельфи) на основе DOM был самый тормознутый, по моему janXML (или как-то так) - самый быстрый парсер XML с открытым исходным кодом... Я бы его брал, тем более это позволит избавиться от DOM (то есть парсер будет работать и под Linux и под Win95/NT4), завязываясь на MS парсеры мы отрезаем возможность использования win ниже 98 и не MS операционных систем. Сейчас SynEdit работает на Kylix/Linux/CLX - дык вот, наш текущий парсер не позволит работать на этих платформах.

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 00:50

А что трудно посмотреть результаты тестов парсеров?

Цитата(Quadr0 @ 25.7.2005, 07:35)

Я уже сказал, что скорость не понизилась.

Не понизилась по сравнению с чем? С тем парсером что я писал? Конечно не понизилась, но это не значит что её нельзя увеличить

DOM однозначно через чур громоздок для этой задачи. Всего-то нужны две операции: загрузка и выгрузка. Динамическая работа (чтение/запись) с XML вести не нужно, а следовательно древовидная структура, которую строит DOM парсер излишне и просто отнимает ресурсы. Для этой задачи лучше всего подходят SAX парсеры.

Для интересующихся:
http://www.saxproject.org/event.html

Конкретные реализации для Делфи:
http://jeffrafter.com/sax/aelfred2/
http://saxforpascal.sourceforge.net/

Fantasist - вот-вот, именно то что я и хотел сказать... Мало того, структура XML достаточно жёсткая, поэтому возможно ускорение парсинга привязкой к конкретной структуре...

Да... DOM действительно не подходит для нашей задачи...

Следующая версия компонента выйдет пока что с парсером TXmlDocument, но после этого надо будет найти ему достойную замену среди SAX-парсеров

Цитата(Quadr0 @ 24.7.2005, 01:03)

Чрезвычайно простое. TXMLDocument более подходит для целей нашего компонента. Дело в том, что TXMLPaser ничего не знает о содержимом документа. Он просто считывает документ от начала до конца. И чтобы, например, считать какой-то определённый блок информации, приходится начинать считывание заново, что чревато потерей времени и уменьшением скорости. Т.к. мы уже заранее знаем где какая тэга находится, то гораздо разумнее использовать TXMLDocumnet, а именно DOM. Он обеспечит быстрый (а точнее, моментальный) доступ к нужной ветке или аттрибуту.

TXMLPaser я еще не смотрел (хотя по беглому взгляду на код могу предположить, что он кривоват). Но все парсеры, которые мне доводилось до этого видеть парсили документ при загрузке (впрочем, как и TXMLDocument, насколько я понимаю). Поэтому последующее обращение к узлам занимало очень малое количество времени. Я даже проводил тесты. TXMLDocument был позади всех. Причем во много раз.

Цитата(Quadr0 @ 24.7.2005, 01:03)

Причём, с гарантией того, что всё сделано правильно. В прошлой версии процедура сохранения писалась сама. Т.е. TXMLParser для этого никак приспособлен не был. Приходилось вручную обрабатывать каждую тэгу и зверски нагромождать код. И никто не мог гарантировать, что могла допуститься ошибка, которая приведёт к тому, что файл подсветки перестанент быть xml совместимым. Теперь о нагромождениях и опасениях за формат можно забыть.

Встроенный в код или сторонний парсер как раз является гарантией того, что все файлы подсветки будут между собой совместимы независимо от амбиций микрософт.

Цитата(Vitalik @ 25.7.2005, 10:08)

А TXmlDocument, кстати, действительно довольно удобен в обращении! smile Загружаешь xml из файла/потока одной процедурой и потом работаешь с xml-документом просто как с деревом smile Удобно!

Vitalik, ты все парсеры в моем сравнении смотрел? Все они позволяют обращаться к документу, как к дереву. Но вызовы имхо более простые, чем через TXmlDocument.

Цитата(Quadr0 @ 25.7.2005, 16:35)

Для систем ниже XP (где нет MSXML.dll) придётся просто эту DLL-ку достать. А её можно выложить на сайте компонента (надеюсь, MS будет не против smile).

Ну а зачем, если можно обойтись без, но дополнительными 50 Кб кода?

Цитата(Fantasist @ 26.7.2005, 17:09)

Для этой задачи лучше всего подходят SAX парсеры.

Не знал о таких.

В общем, я так понимаю пора начинать новый виток тестирования парсеров.

Добавлю к минусам TXmlDocument:
- низкая скорость;
- большой объем (причем совершенно лишний) используемой памяти.

Цитата(s @ 5.8.2005, 21:06)

Vitalik, ты все парсеры в моем сравнении смотрел? Все они позволяют обращаться к документу, как к дереву. Но вызовы имхо более простые, чем через TXmlDocument.

Нет, еще не смотрел... Всё никак не решусь
А надо бы...

Цитата(s @ 5.8.2005, 21:06)

В общем, я так понимаю пора начинать новый виток тестирования парсеров.

Ага! Это было бы очень полезно!
Буду тебе очень признателен!

И спасибо за такое подробное описание всех минусов TXmlDocument!
Ты меня окончательно убедил в необходимости выбора другого парсера для компонента!

Цитата

Для этой задачи лучше всего подходят SAX парсеры.

Тоже не лучшее решение. Оказывается он не поддерживает самой распространенной кодировки - windows-1251:

Цитата

The SAXWriter should be working much better in this release, it natively supports UTF-8 (in Delphi 6 and up) and UTF-16 (it no longer always writes the UTF-16 Byte order mark if the URF-16 encoding is selected), as well as some other 8 bit formats (such as US-ASCII and ISO-8859-1). Additionally a TSAXWriteEx was added to simplify element and data declarations in non-namespaced documents.

Да и объем самих компонентов большой - более 500 Кб в несжатом виде. Кроме того не уверен, что event-based api будет удобнее (20 мегабайт файлов тут ведь не будет?). Кроме того SAX - это тоже COM. Пока тестов производительности не проводил, но думаю, что он все равно не подойдет для этой задачи.

Это сообщение отредактировал(а) s-mike - 6.8.2005, 17:21

Цитата(s @ 6.8.2005, 14:21)

Оказывается он не поддерживает самой распространенной кодировки - windows-1251:

1) В этой цитате не указанно, что она не поддерживается. Говориться, что "поддерживаются также и другие 8-битные кодировки (такие как US-ASCII иISO-8859-1)", но нет упоминания, что это все.

2) SAX - это технология, а не конкретная реализация в этом компоненте. Вряд ли официально декларируется, что SAX не должен поддерживать кодировки кроме таких-то.

Цитата(s @ 6.8.2005, 14:21)

Кроме того SAX - это тоже COM.

Цитата(s @ 6.8.2005, 14:21)

Да и объем самих компонентов большой - более 500 Кб в несжатом виде.

Это все детали реализации. Не нравится компонент - можно найти другой.

Опять же парачка вопросов, насколько полная нужна поддержка стандарта XML? Например, кодировки, если они не поддерживаются SynEdit-ом highlighter'у не помогут. Опять же вряд ли нужны поддержки тегов СData.