petalvik,

Мы говорим с Вами об одном и том же только разными словами

Рассуждая о SAX я рассматриваю данную статью: http://ru.wikipedia.org/wiki/SAX
"SAX-парсинг" в моём понимании - это процесс распарсивания XML, при котором каждая прочитанная единица отправляется системе в соответствующий калбек. Далеко не всегда удобный способ, но зато самый быстрый - потому что требует минимального потребления памяти и не содержит логики увязывания элементов и атрибутов между собой
"DOM-парсинг" в моём понимании - это процесс распарсивания XML, при котором получится иерархическое представление XML-документа, где в простейшем случае элементы будут содержать имя, список атрибутов, значение элемента, список элементов-детей и указатель на элемент-отца; атрибуты - это пара имя/значение. "DOM-парсинг" очень просто построить на основе "SAX-парсинга".
"XML-Binding" - это высокоуровневый механизм для работы с XML-документами. Но это надстройка над DOM.

> назову его pull-парсер, т. к. он не выталкивает данные, а их нужно вытягивать

я таки думаю, что там в основе всё тот же SAX-парсер. Ибо вообще сложно реализовать парсер, который разбирает семантику документа, отслеживает ошибки, перекодирует строки из XML в обычные, улаживает вопросы с кодировкой... Зачем для всего .NET писать несколько парсеров, когда можно написать производительный один, отладить его, и использовать для всех остальных разного уровня задач. Судя по Вашему описанию "pull-парсер" это высокоуровневая надстройка над обычным парсером (который я называю SAX)

> Чтобы ускорить клиентский код, имеется таблица имён (NameTable),
> куда можно занести заранее имена элементов, которые будут в xml,
> и в итоге сравнивать уже не строки (что медленно), а ссылки.

вот мы и подошли к вопросу, который я описывал ещё в самом первом своём сообщении ветки. Для того чтобы оперативно идентифицировать строки, правильнее использовать не сравнения строк, а сравнения ID-констант. В приведённом Вами примере используются не инты, а ссылки. Я о чём и говорю. "NameTable" это механизм отнесения строки к какому-то идентификатору. Для подобных задач хорошо зарекомендовали себя хеш-таблицы. Я сам очень часто использую хеш-таблицы, в том числе и для идентификации строк.

Но! Когда полный список необходимых тебе идентификаторов известен ещё до компиляции, существует в разы более эффективный способ их распознавания. Не нужно выполнять hash-функцию, не нужно хранить и управлять хеш-массивом, не нужно сравнивать строку со строкой в массиве. Я разработал утилиту, которая генерирует код, позволяющий однозначно идентифицировать и с максимальной скоростью. Опять таки посмотрите первое сообщение. Там 6 строк, определяющихся моментально. А может быть сколько угодно.

> Опять же, приведу в пример дотнетовский pull-парсер - он тщательно вылизан,
> с кучей ручных оптимизаций, и работает настолько быстро (бьюсь об заклад, вам его не побить ;) )

я не первый день живу на бренной земле :)
и подобных выражений выслушал уже не один десяток )
и когда проводится очередной тест, на котором моя реализация побеждает в разы, вместо дико восторженных возгласов "отныне ты наш бог и сенсей" я слышу что-то типа "ну для данной задачи особо то дополнительная производительность и не нужна, вот ты столько времени потратил, а мог взять стандартное решение, вот ты реализовал на ассемблере, но твоё решение не кроссплатформенное". Люди редко могут отходить от зарекомендовавших себя подходов. Люди редко способны разглядеть истинные перспективы. (Русские) люди редко искренне порадуются классным идеям других людей. И почти никогда не признают превосходство коллеги над собой

_Vasilisk_

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

мне прям стало интересно
с каких пор желание, умение и опыт делать качественное программное обеспечение стало проявлением неадекватности )

а вообще извольте извиниться

petalvikВ основе парсинга лежит лексер. Он выдаёт поток токенов. Для xml этот токены должны соответствовать Xml Information Set. Что с ним будет делать парсер (принимающий токены от лексера или имеющий его в своём составе) - дело второстепенное. Он может зажигать события (SAX) или просто предлагать информацию об элементах xml (тот самый InfoSet) клиенту.
и в чём состоит разница по Вашему между "лексером" и SAX ?
в любом случае срабатывает событие, идентифицирующее о начале элемента, о поступившем атрибуте, поступившем значение элемента, о конце элемента. Точь в точь функционал SAX. Над которым уже можно стоить надстройки

petalvikИз вашего описания невозможно толком ничего понять.
что конкретно Вам не удалось понять ?
я написал, чтобы было понятно любому школьнику. Может быть Вы не знаете, что такое хеш-массив или ID-константа ?

Antonariy,

а по моему признак неадекватности - совать нос куда только можно. по поводу и без

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

petalvikРазница в том, что лексер выдаёт поток токенов. Парсер выдаёт Infoset. Парсер xml выдаёт Xml Information Set.
в чём отличие:
1) токенов, выдаваемых XML-лексером
2) Infoset для SAX
3) Infoset для pull
4) Infoset для DOM

Antonariy

парсеры парсерам рознь
есть PugiXML, а есть MS XML
и те и те умные. Только одни находчивее других