Самый быстрый xml parser
 

Мне нужен XML парсер, чтобы парсить тяжелые XML.
Подскажите где достать самый быстрый xml parser
Заранее спасибо.

Самый быстрый *— встроенный.
И во что он должен парсить?

в Object было бы неплохо.
XML2Object, например, парсит файл размером 80 кб за 450 мс, а мне мах 250 надо!

Нашел прототип, работает быстрее но меньше 300 не получается :(

Гораздо удобнее было бы похожий метод ХMLNod"у приделать, если уже так сильно нужно. А еще проще - вообще ничего никуда не парсить, ХМЛ сам по себе и так нормально структурирован, зачем усложнять?

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

Ну дык ХМЛ - это уже готовый объект с уже написаными, описанными и хорошо работающими свойствами/методами. Зачем его еще во что-то переделывать? А самое главное, что если вы дождались онЛоада, то это значит, что ХМЛ уже 1 раз парсился (получаете-то вы строку, а не ХМЛ)!
Вот, немного переделал код выше, я думаю, что это то, что мешало (длинные имена) а не плохая структура.

Не совсем по теме...
А как длина имени влияет на скорость кода?

Для того, чтобы по нему было удобнее перемещаться.
Для того, чтобы получить значение nodeName методами XMLNode: firstChild.childNodes[2].firstChild.nodeValue
После того как перегнали в объект: obj.asdf.nodeName
т.е. получается доступ по имени, а не по номеру.

Я сильно сомневаюсь, что влияет. Суть не в этом. Просто, что я пытаюсь сказать, что нужно еще 10 раз подумать, перед тем, как парсить ХМЛ во что-то другое "более удобное". На мой взгляд, гораздо быстрее, практичнее да и красивше - пользоваться встроенным классом, с уже готовыми АПИ, чем создавать что-то свое со схожим функционалом.

Т.е. если вы сможете написать код, который после события onData() ХМЛя выполнится быстрее, чем onLoad() и создаст объект копирующий структуру загруженного ХМЛЯ - я буду вам дико завидовать. =) Но я не верю, что это возможно даже теоретически =) В любом другом случае, на мой взгляд, операция по превращению ХМЛя во что-то другое лишена смысла.
А если вас не устраивают названия методов childNodes и attributes - дык, я не думаю, что можно от них "избавиться" более практично, чем это сделано в моем коде...

udaaf:
А что ты будешь делать, если получишь такой ХМЛ?
=)

Вообще idMap рулит, чтобы не нагружать мозг для придумывания оригинальных названий можно иметь одинаковые, но это при условии что вы написали класс обрабатывающий хмл и возвращающий нод в виде хмл объекта, что по сути не представляет большой проблемы. Лично я вижу несколько плюсов в написании такого класса.

Этот класс был давно написан Макромедией, называется XML %)

Человек спросил, как сделать быстрее, а вы ему предлагаете еще 1 атрибут добавить в его, и без того очевидно не маленький ХМЛ? =))) Хотя, может idMap и рулит куда-то %) я не спорю =)

А я вообще не стороник парсинга. По поводу добавления аттрибута то мне просто сложно представить как вы будете ориентироваться без него в хмл размер которого больше хотя бы 100 нодов.

Разговор про ограниченые возможности класса ХМЛ по сравнению хотя бы с его тёской в Ас3 простой выходит за тему этого топика.

Если xml будет преобразовываться в объект, так и надо в нем описывать структуру объекта, и, соответсвенно, исключать одинаковые имена. Ну а такой xml как ты в пример привел, конечно же нет смысла в объект преобразовывать, потому что узлы пришлось бы в массив поскладывать и получилось бы суть тоже самое.

Да елки, ну как это еще сказать... конструктор ХМЛя что принимает? - строку, когда ХМЛ загружается извне, что он получает? - правильно, строку. Вот, когда он создается конструктором или parseXML - вот тогда и происходит парсинг %) Я это и пытаюсь донести, что парсить 2 раза - бессмысленно. Не нравится, как это делает встроенный класс? - вам все карты в руки, пишите сами, по большому счету лоадВарз от ХМЛ.лоад мало чем отличается. Вот только смысла в такой операции я не вижу. Зачем переделывать то, что уже реализовано на уровне родных встроенных в плеер функций? И АС3 тут явно ни при чем...

Скажем по-другому, это часто встречающееся заблуждение, что для того, чтобы было "удобно", нужно загруженный ХМЛ во что-то трансформировать. На самом деле же, родная структура ХМЛя достаточно удобна, а главное - быстро работает, и нет смысла переделывать его во что-то другое.

udaaff:
Ну, тогда следующий вопрос =) А зачем тебе нужно такое преобразование, которое. 1. работает медленно. 2. имеет мало преимуществ перед встроенными возможностями (положа руку на серде - никаких). 3. не в состоянии обработать все возможные ситуации.
ХМЛ в посте выше - вполне нормальный ХМЛ, любой браузер его отобразит не выдавая сообщения об ошибках (да и с какой стати?). Так почему созданый тобой мегаудобный парсер будет глючить, получи он такой безобидный ХМЛ? %)
Та же ерунда и с idMap - ну, хорошо, если вы сами автор вашего ХМЛя, и знаете, что атрибут id не должен дублироваться. А что если автор не вы? Переписываться с заказчиком, и обьяснять ему, что ДБ которую он строил несколько месяцев, заплатил за нее N$ и работающую хорошо во всех остальных ситуациях он не сможет связать с вашей флешкой? Честно, шанс после таких объяснений быть посланным\уволенным => бесконечность =)

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

По поводу идМапа, смотри пост выше, сорри если немного резко выразился. Ничего личного, скорее личный опыт =)

Оно нужно тогда, когда нужен объект =) К примеру, в программе имется много настроек, и любая из них может понадобится в процессе работы программы, и мне кажется тут гораздо удобнее было бы настроики эти получать по именам, а не высчитывать на калькуляторе, где они там находятся =)