LINUX.ORG.RU

Статья о производительности xml-парсеров

 , ,


0

0

Scott Sanders опубликовал статью с результатами сравнения различных xml-парсеров. Проверке подверглись как известные продукты, такие как RapidXml, DOM4J, libxml2sax, Java6, так и менее известные - Aalto, Javolution, Woodstox, StaX, phobos и Tango.

По результатам сравнения видно, что с задачей обработки файлов одинакового объема быстрее всех справляется Tango pull parser. С небольшим отставанием идут Tango SAX, Tango DOM и RapidXml.

>>> XML Benchmarks - pros and cons of each library

>>> Why is D/Tango so fast at parsing XML?

>>> Результаты

★★★★★

Проверено: Shaman007 ()

Re: Статья о производительности xml парсеров

Насколько я помню, никто и не считал, что D - отстой. Просто ему будет сложно конкурировать с уже устоявшимися гигантами. А парсер, аналогичный по скорости Tango можно написать и на C/C++, хоть и будет он ужасно страшным. Тут вся заслуга в квалификации автора - Kris Bell. Исходники, кстати, открыты: www.dsource.org/projects/tango/browser

naryl ★★★★★ ()

Re: Статья о производительности xml парсеров

> Ну, кто-нибудь еще считает, что D - отстой?

Если писать исключительно XML-парсилки, то D - мой выбор! Аминь.

Дайте ему устаканиться, обрости библиотеками и биндингами, а потом уже сравнивайте его со старожилами.

troorl ★★ ()

Re: Статья о производительности xml парсеров

> Дайте ему устаканиться, обрости библиотеками и биндингами, а потом уже сравнивайте его со старожилами.

+1 Этот тест доказывает, что на D можно написать _очень_ быструю xml парсилку, а на java - нет, но не более.

Чтобы добрые люди не копались в глубокой древовидной структуре: http://www.dsource.org/projects/tango/browser/trunk/tango/text/xml

PS Сам давно предпочитаю D для личных проектов.

naryl ★★★★★ ()

Re: Статья о производительности xml парсеров

> на предприятиях кодебейз С/С++ переписывать в него точно не будут.

А что, _новых_ приложений на Си/Си++ больше не нужно? Именно на это нацелен D.

tailgunner ★★★★★ ()

Re: Статья о производительности xml-парсеров

anonymousl, дизайнер языка лично сказал, что уже имеющиеся приложения на нем переписывать не надо.

alex_custov, обещали добавить. Следи за блогом.

JackYF, http://www.prowiki.org/wiki4d/wiki.cgi?action=browse&id=GuiLibraries&... Я использую fltk4D.

naryl ★★★★★ ()
Ответ на: Re: Статья о производительности xml-парсеров от alex_custov

Re: Статья о производительности xml-парсеров

> ЛОР-эффект, однако

Первый раз наблюдаю ЛОР-эффект в действии. :) Буквально 10 минут назад по этой самой ссылке ходил.

naryl ★★★★★ ()

Re: Статья о производительности xml-парсеров

А может кто-нибудь в двух словах расписать, как оно работает? То есть, его особенности я в общих чертах знаю, но как они достигаются?

troorl ★★ ()

Re: Статья о производительности xml-парсеров

C++ можно привязать через C. Подругому никак. Только если переписать.

А адепты M$ один @#$ будут .NET продвигать, независимо от того, что лучше и удобнее.

naryl ★★★★★ ()

Re: Статья о производительности xml-парсеров

Если X создано ради X, то X = отстой.

mono = отстой, d = отстой, windows = отстой.

C = ъ, Perl = Ъ, UNIX= Ъ.

Дальше сами.

ip1981 ☆☆ ()

Re: Статья о производительности xml парсеров

> А парсер, аналогичный по скорости Tango можно написать и на C/C++, хоть и будет он ужасно страшным.

Не страшным, а просто недоступным для понимания людям с улицы.

Displacer ★★ ()

Re: Статья о производительности xml парсеров

> А что, _новых_ приложений на Си/Си++ больше не нужно?

Приложения нужны, но еще нужнее грамотные люди, которые будут их писать. С этим нынче напряг, все ушли на жаводотнет.

Displacer ★★ ()

Re: Статья о производительности xml парсеров

На жаводотнет ушли неосилившие C/C++, и в этом нет ничего плохого... почти. Пусть лучше человек пишет глючные программки жаводотнете, чем не пишет вообще.

naryl ★★★★★ ()

Re: Статья о производительности xml-парсеров

>http://www.prowiki.org/wiki4d/wiki.cgi?action=browse&id=GuiLibraries&;... Я использую fltk4D.

Жить уже потихоньку можно. Пожелаем удачи проекту.

P.S. Пока юзаем C++/Qt... :)

eduard_pustobaev ★★ ()
Ответ на: Re: Статья о производительности xml-парсеров от eduard_pustobaev

Re: Статья о производительности xml-парсеров

Согласно главной странице проекта flkt4d, оно использует С++-код, поэтому там какие-то затыки со сборкой мусора. А нафиг тогда оно надо, если Qt есть?

Есть там один гуй на OpenGL, но он уже как полгода не разивается. Остаётся... официальный dwt. Кстати, а gdc с dwt дружит-то?

JackYF ★★★★ ()

Re: Статья о производительности xml парсеров

Деньги решают ^_^

Только сегодня разговаривал с работником фирмы обслуживающей всякие банки. Легаси софта на коболе говорит еще полно.

anonymousI ()

Re: Статья о производительности xml-парсеров

Я, помнится, интереса ради проводил замеры втягивания 20-мегабайтного xml с помощью нескольких парсеров для плюсов (xerces-c, boost::property_tree, libxml++), и перетягивание в s-exp в Емаксе и sbcl (xml.el в emacs, xmls в sbcl. Медленнее всех оказался property_tree, а быстрее всех - sbcl и xmls. xml.el. Интерпретируемый elisp оказался где-то в середине.

mv ★★★★★ ()

Re: Статья о производительности xml парсеров

> Деньги решают ^_^

Решает for fun, а деньги - бумага. Не так ли, товарищи линуксоиды?
*неуверенный голос из аудитории* истинно так, товарищ Жуков.

troorl ★★ ()

Re: Статья о производительности xml парсеров

>На жаводотнет ушли неосилившие C/C++, и в этом нет ничего плохого... почти. Пусть лучше человек пишет глючные программки жаводотнете, чем не пишет вообще.

Чушь и провокация, вы либо совсем не в теме либо пионер короткие штанишки.

satellite13 ()

Re: Статья о производительности xml парсеров

>А зачем он нужен? Для институтских поделий - возможно. А на предприятиях кодебейз С/С++ переписывать в него точно не будут.

Когда-то точно также зарекались от переписывания тонн софта на FORTRAN и COBOL :D

KRoN73 ★★★★★ ()

Re: Статья о производительности xml-парсеров

>Если X создано ради X, то X = отстой.

>mono = отстой, d = отстой, windows = отстой.

>C = ъ, Perl = Ъ, UNIX= Ъ.

Вот буквально в соседнем топике рвали тельняшку на груди, утверждая, что mono писался для Gnome. По этой трактовке выходит, что mono - Ъ :)

KRoN73 ★★★★★ ()

Re: Статья о производительности xml-парсеров

> Согласно главной странице проекта flkt4d, оно использует С++-код, поэтому там какие-то затыки со сборкой мусора.

Суть в том, что fltk4D своевременно убирает объекты fltk используя reference counting. Никаких затыков. По крайней мере утечек памяти быть не должно.

naryl ★★★★★ ()

Re: Статья о производительности xml-парсеров

Уже давно пытаюсь осилить D... Вот пока что нарыл:
1) GUI - http://www.dsource.org/projects/dwt, скрины - http://www.dsource.org/projects/dwt/wiki/ControlExample . Насчет GDC написано "not tested", но думаю работать должно - D 2.0 фичей не требует.
Есть еще DFL с Entice(IDE+form editor), но оно пока windows-only. Хотя от портирования автор не отказывался.
2) IDE - http://www.dsource.org/projects/poseidon . Написана на DWT, значит он вполне юзабельный, да и работа идет.
3) Библиотеки - http://www.dsource.org/projects/tango/wiki/Features .
Весьма немаленький список, да и бинарная совместимость с Си-либами есть.
4) Отладчик - http://ddbg.mainia.de/releases.html .

Для моих жалких студенческих поделий (компилятор недопаскаля) D вполне подходит.

//captcha lipter

anonymous ()

Re: Статья о производительности xml парсеров

> На жаводотнет ушли неосилившие C/C++

Жаба душит? Джава-программисты спать спокойно не дают? А по существу есть что сказать?

Bioreactor ★★★★★ ()

Re: Статья о производительности xml-парсеров

Я так понимаю, что сервак с блогом тоже на D написан?

anonymous ()

Re: Статья о производительности xml-парсеров

Sounds like one of the design choices is to ignore DTDs and entities. Fine, but they shouldn't call what they are parsing XML. By definition, this is not an XML parser.

No solution that requires the entire XML file be in memory can be called memory efficient. XML files are often program-generated data files and can be hundreds to thousands of megabytes long. OTOH, if their parser works out of a buffer and doesn't guarantee that array slices are valid after they are reported, they have some interesting buffer boundary issues. Further, if the parser is used DOM-style, there is no reduction in memory allocation; they are just passing the memory allocation burden to the parser user.

Как правильно замечают иностранные коллеги, сравнивали непонятно что с непонятно чем. Да, быстро, но - только в памяти, и - не XML-парзер, а "библиотека, обрабатывающая нечто, отдаленно похожее на XML".

stellar ()

Re: Статья о производительности xml парсеров

>усть лучше человек пишет глючные программки жаводотнете, чем не пишет вообще.

Пусть лучше человек торгует телом, чем не торгует вообще.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.