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

[telit]

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

[etc]

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

[telit]

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

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


XML.prototype.toObject = function ()
{
var $xparse = function (n)
{
var o = new String (n.firstChild.nodeValue), s, i, t
for (s = (o == "null") ? n.firstChild : n.childNodes[1]; s != null; s = s.nextSibling)
{
t = s.childNodes.length > 0 ? arguments.callee (s) : new String (s.nodeValue)
for (i in s.attributes) t[i] = s.attributes[i]

if (o[s.nodeName] != undefined)
{
if (!(o[s.nodeName] instanceof Array)) o[s.nodeName] = [o[s.nodeName]]
o[s.nodeName].push (t)
}
else o[s.nodeName] = t
}
return o
}
return $xparse (this)
}

[wvxvw]

Гораздо удобнее было бы похожий метод ХMLNod"у приделать, если уже так сильно нужно. А еще проще - вообще ничего никуда не парсить, ХМЛ сам по себе и так нормально структурирован, зачем усложнять?
XMLNode.prototype.__resolve = function(p):Object {
return this.attributes[p];
}
var myXML:XML = new XML("<node a='0'><sub1 a='1'/><sub1 a='2'/><sub1 a='3'/><sub2 a='4'/><sub2 a='5'/></sub1><sub1 a='6'/></node>");
trace(myXML.childNodes[0].a);
trace(myXML.childNodes[0].childNodes[0].a);

[telit]

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

[wvxvw]

Ну дык ХМЛ - это уже готовый объект с уже написаными, описанными и хорошо работающими свойствами/методами. Зачем его еще во что-то переделывать? А самое главное, что если вы дождались онЛоада, то это значит, что ХМЛ уже 1 раз парсился (получаете-то вы строку, а не ХМЛ)!
Вот, немного переделал код выше, я думаю, что это то, что мешало (длинные имена) а не плохая структура.
XMLNode.prototype.__resolve = function(p):Object {
if(!isNaN(p/1)){
return this.childNodes[p];
} else {
return this.attributes[p];
}
}
var myXML:XML = new XML("<node a='0'><sub1 a='1'/><sub1 a='2'/><sub1 a='3'/><sub2 a='4'/><sub2 a='5'/></sub1><sub1 a='6'/></node>");
trace(myXML.childNodes[0].a);
trace(myXML.childNodes[0].childNodes[0].a);
trace(myXML[0][0].a);

[terbooter]

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

[udaaff]

Ну дык ХМЛ - это уже готовый объект с уже написаными, описанными и хорошо работающими свойствами/методами. Зачем его еще во что-то переделывать? Для того, чтобы по нему было удобнее перемещаться.
<root>
<node>value</node>
<text>tratata</text>
<asdf>
<nodeName>name</nodeName>
</asdf>
</root>
Для того, чтобы получить значение nodeName методами XMLNode: firstChild.childNodes[2].firstChild.nodeValue
После того как перегнали в объект: obj.asdf.nodeName
т.е. получается доступ по имени, а не по номеру.

[wvxvw]

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

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

udaaf:
А что ты будешь делать, если получишь такой ХМЛ?
<root>
<node>value</node>
<text>tratata</text>
<asdf>
<nodeName>name</nodeName>
</asdf>
<asdf>
<nodeName>name</nodeName>
</asdf>
</root> =)

[screamge]

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

[wvxvw]

...но это при условии что вы написали класс обрабатывающий хмл и возвращающий нод в виде хмл объекта...
Этот класс был давно написан Макромедией, называется XML %)

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

[screamge]

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

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

[udaaff]

А что ты будешь делать, если получишь такой ХМЛ?
Код:
<root>
<node>value</node>
<text>tratata</text>
<asdf>
<nodeName>name</nodeName>
</asdf>
<asdf>
<nodeName>name</nodeName>
</asdf>
</root>
=)
Если xml будет преобразовываться в объект, так и надо в нем описывать структуру объекта, и, соответсвенно, исключать одинаковые имена. Ну а такой xml как ты в пример привел, конечно же нет смысла в объект преобразовывать, потому что узлы пришлось бы в массив поскладывать и получилось бы суть тоже самое.

[wvxvw]

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

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

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

[screamge]

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

[wvxvw]

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

[udaaff]

udaaff:
Ну, тогда следующий вопрос =) А зачем тебе нужно такое преобразование, которое. 1. работает медленно. 2. имеет мало преимуществ перед встроенными возможностями (положа руку на серде - никаких). 3. не в состоянии обработать все возможные ситуации.

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