я очень люблю питон. просто обожаю. на нем я продуктивен как собака баскервилей. но все чаще и чаще замечаю, что вместо решения насущных проблем, я решаю проблему производительности питона, извращаясь самым непотребным образом. в частности, задача разбивка файла на строки это десяток функций, опирающихся на string.find с концепций головы и хвоста (подразумевается, что файл может использовать \x0A, \x0D, \x0D\x0A в качества маркера конца строки, в том числе и все три представления внутри одного файла).
Регулярное выражение (\x0D\x0A|\x0A|\x0D|$) работает не быстрее асфальтоукладчика, который толкают по бездорожью бурлаки. Библиотеки типа re2 равно как и pypy не позволяют добиться сколь-нибудь существенного увеличения производительности.
У меня есть два пути: а) реализовать примитивы на Си, вызываемые из питона; б) забить на питон и выбрать другой язык.
И вот перед началом довольно масштабного проекта я задумался о nemerle. Надеюсь, это послужит рекламой/бустером для nemerle. Отсюда к сообществу разработчиков у меня есть пара вопросов:
1) будет ли оно работать под Linux и Mac OS? Если да, то какие компоненты необходимо устанавливать?
2) производительность. главным образом интересует с какой скоростью код на nemerle может распарсить хотя бы такой простой формат как pdf. поскольку я не знаком с языком, то пробовать оценивать производительность программы, написанной в процессе изучения языка, я не берусь. если вас не затруднит, не могли бы вы написать скелет очень простого парсера для pdf наподобие этого: http://www.gnupdf.org/Introduction_to_PDF
все парсить не обязательно. Достаточно выполнить разбивку на объекты и потоки, т.е. парсер должен возвращать что-то типа этого:
x y obj # возвращаем номер объекта (x, y)
<<
# возвращаем в сыром виде то, что в угловых скобках >>
stream
# возвращаем что между stream и endstream, обрасывая первый и последний переносы строки (контент может содержать нули)
endstream
endobj
в свою очередь обещаю продвигать nemerle всеми силами
PS. если у вас нет времени на это, то просьба написать скелет, возвращающий позиции x y obj, начинающиеся с новой строки. заранее спасибо.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re: # nemerle -- better an egg today than a hen tomorrow
Здравствуйте, мыщъх, Вы писали:
М>...обращаясь к nemerle community
И ты мыщъх ?
М>И вот перед началом довольно масштабного проекта я задумался о nemerle. Надеюсь, это послужит рекламой/бустером для nemerle. Отсюда к сообществу разработчиков у меня есть пара вопросов:
М>1) будет ли оно работать под Linux и Mac OS? Если да, то какие компоненты необходимо устанавливать?
Mono, желательно посвежее.
Бинарники работают с ним проблем.
Есть проблема собрать компилятор , но думаю этого не требуется.
М>2) производительность. главным образом интересует с какой скоростью код на nemerle может распарсить хотя бы такой простой формат как pdf. поскольку я не знаком с языком, то пробовать оценивать производительность программы, написанной в процессе изучения языка, я не берусь. если вас не затруднит, не могли бы вы написать скелет очень простого парсера для pdf наподобие этого: http://www.gnupdf.org/Introduction_to_PDF
Если речь зашла о парсерах, то тут наилучшую производительность разработки и кода дадут только генераторы парсеров.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, мыщъх, Вы писали:
_NN>Если речь зашла о парсерах, то тут наилучшую производительность разработки и кода дадут только генераторы парсеров.
на си машина состояний очень быстро работает и все упирается в ввод-вывод. производительность не самоцель. просто когда тестовый набор файлов проверяется больше суток на топовом железе на компилирующем трансляторе питона это мрак. а потому встает вопрос какой язык выбрать.
обдумываю вариант си + питон. на си можно получить автоматически сгенерированный парсер, вызываемый из питона, на котором написан высокоуровневый клей. но... это слишком поморочено. если nemerle позволяет это делать средствами самого nemerle -- я бы на это с удовольствием посмотрел, а так на си и готовые парсеры есть. остается пристыковать их к питону. главный минус такого решения -- адоба не следует своей же спецификации и открывает файлы, которые открываться не должны и опенсурсные проекты типа Ghost Script на них падают. и каждое такое падение означает, что нам нужно изменить описание парсера, сгенерировать новый код на си, откомпилировать и обновить библиотеку на питоне, убедившись, что скрипт ее подхватил (при определенных обстоятельствах питон продолжает использовать старую). очень много гемора. хотелось бы концепцию "все-в-одном".
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Re[3]: # nemerle -- better an egg today than a hen tomorrow
Здравствуйте, _NN_, Вы писали:
_NN>Тогда стоит подождать авторов Nitra , надеюсь там как раз есть то что нужно.
Для этой задачи лучше взять PegGrammar.
Nitra создаётся для других задач и имеет кучу лишнего функционала, который будет тормозить, и жрать память почем зря. И проблемы что описаны ниже, у Nitra тоже есть. И устранить их будет намного сложнее.
Но и с PegGrammar в данном случае не всё хорошо.
Он работает с юникодом. И у него нет возможности разобрать
Stream (<< /Length ... >> stream ... endstream): embedded data, can be compressed. It starts with a dictionary that describes the stream such as its length or the encoding (/Filter) is uses.
Но в принципе должно быть не сложно поправить PegGrammar, так чтобы устранить оба недостатка.
Вообще я думаю, что стоит PegGrammar развивать в направлении парсера бинарных форматов.
Если кто-то хочет этим заняться, то могу что надо подсказать.
У меня самого на это времени нет. Всё съедает Nitra.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: # nemerle -- better an egg today than a hen tomorrow
Здравствуйте, WolfHound, Вы писали:
WH>Он работает с юникодом. И у него нет возможности разобрать
Это элементарно лечится. Нужно только символ на байт заменить.
WH>
WH>Stream (<< /Length ... >> stream ... endstream): embedded data, can be compressed. It starts with a dictionary that describes the stream such as its length or the encoding (/Filter) is uses.
С этим сложнее. Но можно прикрутить рукопашные продукции. Как правило, но вызвает некоторый пользовательский метод который может сдвинуть позицию парснинга.
WH>Но в принципе должно быть не сложно поправить PegGrammar, так чтобы устранить оба недостатка.
Есть еще третий. Для бинарных форматов может потребоваться потоковый парсинг, а PEG он предполагает загрузку разбираемых данных в память. А вот это уже не лечится никак.
Если же разбор идет по документно, то проблем нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: # nemerle -- better an egg today than a hen tomorrow
Здравствуйте, мыщъх, Вы писали:
М>...обращаясь к nemerle community
М>я очень люблю питон. просто обожаю. на нем я продуктивен как собака баскервилей. но все чаще и чаще замечаю, что вместо решения насущных проблем, я решаю проблему производительности питона, извращаясь самым непотребным образом. в частности, задача разбивка файла на строки это десяток функций, опирающихся на string.find с концепций головы и хвоста (подразумевается, что файл может использовать \x0A, \x0D, \x0D\x0A в качества маркера конца строки, в том числе и все три представления внутри одного файла).
М>Регулярное выражение (\x0D\x0A|\x0A|\x0D|$) работает не быстрее асфальтоукладчика, который толкают по бездорожью бурлаки. Библиотеки типа re2 равно как и pypy не позволяют добиться сколь-нибудь существенного увеличения производительности.
Регэкспы в джаваскрипте, в частности как у тебя, работают намного быстрее чем в питоне. Есть либа, в двух вариантах, js и питон, код один к одному и разница в перформансе внушает, почти в 10 раз.
Re[5]: # nemerle -- better an egg today than a hen tomorrow
Здравствуйте, WolfHound, Вы писали:
WH>Вообще я думаю, что стоит PegGrammar развивать в направлении парсера бинарных форматов.
Мне та же мысль пришла в голову, когда прочитал про Melange — DSL для сетевых протоколов на хабре. В общем-то в Немерле было бы все, что бы сделать подобный DSL — Statechart и PegParser, если бы PegParser мог парсить не только текст, но и бинарные данные.
Re[6]: # nemerle -- better an egg today than a hen tomorrow
Здравствуйте, anton_t, Вы писали:
_>...если бы PegParser мог парсить не только текст, но и бинарные данные.
Это как раз меньшая из проблем решаемая за пол часа (заменой строки на массив байтов).
Основная проблема заключается в том, что бинарные форматы в основном контекстно зависимые, а PEG рассчитан на разбор контекстно-свободных грамматик (за небольшим исключением).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: # nemerle -- better an egg today than a hen tomorrow
Здравствуйте, WolfHound, Вы писали:
WH>Nitra создаётся для других задач и имеет кучу лишнего функционала, который будет тормозить, и жрать память почем зря. И проблемы что описаны ниже, у Nitra тоже есть. И устранить их будет намного сложнее.
А что нельзя отключить лишний функционал, если он не используется?
А как же модульность, гибкость архитектуры и юнит тесты?
Re[6]: # nemerle -- better an egg today than a hen tomorrow
Здравствуйте, HrorH, Вы писали:
HH>А что нельзя отключить лишний функционал, если он не используется?
Коротко: Нельзя.
Длиннее:
— У вас такая классная сортировка. Могу я с её помощью найти минимум в потоке из миллиарда интов?
— Можешь. Но сортировка не для этого предназначена. Будет тормозить, и жрать память.
— А как же модульность, гибкость архитектуры и юнит тесты?
Вот такой разговор получился.
Общего у нитры и парсера бинарных форматов примерно столько же, как у феррари и белаза. И одно в другое не переделать никаким тюнингом.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
