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?

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

ЗАСТАВЬ КОМПЬЮТЕР ПОЛИВАТЬ ОГОРОД

автоматизация своими руками: электроприборы под контролем компьютера
beware of programmers who carry screwdrivers!
http://www.unicontrollers.com/products/unc01x

[#]  
ShprotX

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

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

* ()
[#] Ответ на: Re: Статья о производительности xml парсеров от ShprotX 13.03.2008 22:53:47  

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

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

*** ()
[#] Ответ на: Re: Статья о производительности xml парсеров от ShprotX 13.03.2008 22:53:47  

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

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

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

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

** ()
[#] Ответ на: Re: Статья о производительности xml парсеров от ShprotX 13.03.2008 22:53:47  
anonymousI

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

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

* ()
[#]  
alex_custov

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

А где expat ? :)

**** ()
[#]  
JackYF

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

Кто знает неплохой гуй под D?

*** ()
[#] Ответ на: Re: Статья о производительности xml парсеров от troorl 13.03.2008 23:08:20  

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

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

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

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

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

*** ()
[#] Ответ на: Re: Статья о производительности xml парсеров от anonymousI 13.03.2008 23:10:11  

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

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

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

***** ()
[#]  

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

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

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

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

*** ()
[#] Ответ на: Re: Статья о производительности xml-парсеров от alex_custov 13.03.2008 23:12:20  

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

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

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

*** ()
[#]  

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

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

** ()
[#] Ответ на: Re: Статья о производительности xml-парсеров от anonymous 13.03.2008 23:19:11  

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

> Вроде GTK+ пытаются прикрутить

DUI - объектно-ориентированная обертка. Саму GTK+ можно использовать прямо из D.

*** ()
[#] Ответ на: Re: Статья о производительности xml-парсеров от naryl 13.03.2008 23:15:46  
anonymousI

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

Блогу плохо. Так нужно С++ переписывать или нет?

А что делать адептам мелкософт, которых в ынтерпрацзе завались?

* ()
[#] Ответ на: Re: Статья о производительности xml-парсеров от anonymousI 13.03.2008 23:31:11  

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

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

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

*** ()
[#]  
ip1981

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

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

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

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

Дальше сами.

## ()
[#] Ответ на: Re: Статья о производительности xml парсеров от naryl 13.03.2008 23:01:27  

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

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

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

* ()
[#] Ответ на: Re: Статья о производительности xml парсеров от tailgunner 13.03.2008 23:12:59  

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

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

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

* ()
[#] Ответ на: Re: Статья о производительности xml парсеров от Displacer 13.03.2008 23:46:26  

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

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

*** ()
[#] Ответ на: Re: Статья о производительности xml-парсеров от eduard_pustobaev 14.03.2008 0:01:42  
JackYF

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

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

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

*** ()
[#] Ответ на: Re: Статья о производительности xml парсеров от JackYF 14.03.2008 0:16:54  
anonymousI

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

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

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

* ()
[#]  
mv

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 оказался где-то в середине.

***** ()
[#] Ответ на: Re: Статья о производительности xml парсеров от anonymousI 14.03.2008 0:26:57  

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

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

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

** ()
[#] Ответ на: Re: Статья о производительности xml парсеров от naryl 13.03.2008 23:51:58  

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

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

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

()
[#] Ответ на: Re: Статья о производительности xml парсеров от anonymousI 13.03.2008 23:10:11  
KRoN73

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

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

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

***** ()
[#] Ответ на: Re: Статья о производительности xml-парсеров от ip1981 13.03.2008 23:41:35  
KRoN73

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

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

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

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

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

***** ()
[#] Ответ на: Re: Статья о производительности xml-парсеров от JackYF 14.03.2008 0:16:29  

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

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

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

*** ()
[#] Ответ на: Re: Статья о производительности xml парсеров от anonymousI 14.03.2008 2:37:13  

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

> Новый мутант ЖабоЦеПепе

4.2

Революционность (эволюционность) пару раз уже обсуждалась. Воспользуйтесь поиском.

*** ()
[#]  

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 парсеров от naryl 13.03.2008 23:51:58  
Bioreactor

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

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

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

*** ()
[#]  

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".

* ()
[#] Ответ на: Re: Статья о производительности xml парсеров от naryl 13.03.2008 23:51:58  

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

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

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

anonymous ()
[#] Ответ на: Re: Статья о производительности xml парсеров от Bioreactor 14.03.2008 9:51:58  

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

>А по существу есть что сказать?

>Bioreactor (*) (14.03.2008 9:51:58)

ААА! Говорящий биореактор!

anonymous ()