Для нейтива скорость порядка гига символов в секунду получается на аналогичный тестах, если входной алфавит имеет буквально единицы символов (как оно бывает на простых регулярных выражениях). Полноценный же лексер, который побъет на токены входной юникодный поток для ЯП, не дает более 400-500 символов/с. Никак. По крайней мере на современной машинке с 4ГГЦ тактовой. Это скорость ровно двух табличных переходов в цикле и одного if. Хотя, в MB/c по прежнему около гига, это же юникод. Но не интересуют реально MB/c, интересно именно символов/с.
V>>Что касается моего кода, то в избранном полно всяческих сниппетов за разные годы (в "файлах" тоже). Давал коллегам как подсказки/решения.
K>Меня интересует тема, которая обсуждается конкретно сейчас — парсеры. Ты вдребезги раскритиковал чужое решение, но показать свое упорно отказываешься
Ну кидай сюда коммерчесский код фирмы, на которой работаешь. Причем целиком, чтобы компиллировалось и запускалось. А я на него посмотрю, сугубо для удовлетворения собственного любопытства.
V>>Кто-то должен был сказать что-то в ответ на все эти наезды.
K>Пока что ты не сказал ничего, кроме похвальбы и пустозвонства.
Считай как хочешь. В технических спорах принято обсуждать технические моменты. А т.к. опоненты, вместо обсуждения технической стороны вопроса скатываются исключительно на понты, то и всё т.н. "обсуждение" прошло в этом ключе. А началось оно вот тут: http://rsdn.ru/forum/philosophy/4247637.1.aspx
Здравствуйте, vdimas, Вы писали:
V> Ну кидай сюда коммерчесский код фирмы, на которой работаешь. Причем целиком, чтобы компиллировалось и запускалось. А я на него посмотрю, сугубо для удовлетворения собственного любопытства.
Интересный у тебя код, если ты не можешь сделать простенький парсер без всего остального кода твоей фирмы
V>Считай как хочешь. В технических спорах принято обсуждать технические моменты. А т.к. опоненты, вместо обсуждения технической стороны вопроса скатываются исключительно на понты
Обсуждение технических моментов на словах ни к чему кроме понтов и не может привести. Я полагаю, здесь все не раз встречались с мастерами почесать языком.
Здравствуйте, VladD2, Вы писали:
VD>Это просто пример. Понятно, что предикат может быть намного сложнее и в добавок не один (да и в разных местах).
Я вообще не уверен что ПЕГом это можно сделать... PEG vs "прыгающий" else
VD>Почему не может случиться так, что в одном месте грамматики автору захочется сматчить более короткий вариант, в другом более длинный?
Для людей это более интуитивно. Да и сам ПЕГ тут похоже тоже не поможет. Хотя строго доказывать мне лень.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Ты же прекрасно знаешь в чем причина. Любая солидная контора всегда будет пытаться разработать компилятор ЯП с парсером по LL(1). Почему именно так, надеюсь известно?
Не ЛЛ(1), а top-down.
Ибо у bottom-up сообщения об ошибках никакие.
V>И почему не катят автогенерилки для LL(1) надеюсь тоже?
По тому что LL(1) убог что звездец.
V>Отсюда вывод — возиться с доработкой вашего парсера вообще нет смысла, пока вы упираетесь в GC. Но твои понты в тех постах, типа "ты ничего не угадал, это ни на что не влияют, нифига ты в парсерах не шаришь" таки показательны.
Ну что поделать если оно так и есть.
Пальци ты тут гнешь круто, а ничего показать не можешь.
V>Ты понятие не имел, что именно у вас влияет больше всего. Хотя я не раз пытался спросить, как и что именно вы замеряете — но ты не проникся ситуацией.
Я тебе сразу сказал и что и как.
V>Он нужен там, где и даром не нужно AST. Т.е. фактически везде, кроме узкой области компиляторостроения под ЯВУ. Для сравнения, компиляторов ЯВУ в активной разработке вряд ли больше нескольких сотен по всему миру (ну или единиц тысяч), а только лишь среду ANTLR качают по 5тыщ экземпляров в месяц.
Ну покажи мне что может это твое Parser tree чего не может мой парсер.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
K>>Некрасиво выглядит.
V>Хм. Никто не просил тыкать нам в лицо некий код из открытого проекта, как доказательство собственной "крутости". Мне думается, что среди коллег сие не принято. По крайней мере, везде , где я работал. Вышел типичный epic fail. Да, не у всех в реальных проектах всегда код идеален, тем более, что идеальность кода далеко не на первом месте по приоритетам. Но мы его никому и не тыкаем...
Такой фонтан в ответ на два слова! Супер!!!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
V>>Хм. Никто не просил тыкать нам в лицо некий код из открытого проекта, как доказательство собственной "крутости". Мне думается, что среди коллег сие не принято. По крайней мере, везде , где я работал. Вышел типичный epic fail. Да, не у всех в реальных проектах всегда код идеален, тем более, что идеальность кода далеко не на первом месте по приоритетам. Но мы его никому и не тыкаем. WH>Ты не понял ничего. WH>Совсем. WH>Ни моих притензий к преподам. WH>Ни зачем я показал тот кусок кода. WH>Ни то что там происходит. WH>Ни то какие там действительно есть проблемы.
Сдается он просто большой и толстый тролль. Его не слушать, а банить надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Сдается он просто большой и толстый тролль. Его не слушать, а банить надо.
Собственно, ЧТД. Стоило ответить вам в вашем же стиле. Только насчет тролля ты ошибся, ибо всё по делу, с аргументами и цифрами. Ты как думал, легко было абстрагироваться от понтов и хамства, пытаясь уловить столь редкие фразы по существу? Потренируйся на досуге, побудь в нашей шкуре.
ИМХО, тебя давно бы пожизненно забанили, будь это третьесторонний по отношению к тебе сайт. Чтобы другим не повадно было.
Здравствуйте, Klatu, Вы писали: V>> Ну кидай сюда коммерчесский код фирмы, на которой работаешь. Причем целиком, чтобы компиллировалось и запускалось. А я на него посмотрю, сугубо для удовлетворения собственного любопытства. K>Интересный у тебя код, если ты не можешь сделать простенький парсер без всего остального кода твоей фирмы
using System;
using System.Collections.Generic;
namespace EDILib.X12
{
internal class X12Linker
{
private class State
{
public readonly State PrevState;
public readonly LinkerNode Node;
public State(State prevState, LinkerNode node)
{
PrevState = prevState;
Node = node;
}
}
private readonly X12Transaction _transaction;
private readonly Stack<string[]> _nonResolvedSegments = new Stack<string[]>(16);
private List<State> _variants = new List<State>(16);
private List<State> _buff = new List<State>(16);
public X12Linker(X12Transaction transaction)
{
_transaction = transaction;
LinkerNode root = transaction.Descriptor.LinkerTree;
_variants.Add(new State(null, root));
}
public void ProcessNext(List<string> segData)
{
_buff.Clear();
string segName = segData[0];
foreach (State state in _variants)
{
LinkerNode node = state.Node;
LinkerNode[] next = node.GetTransition(segName);
switch (next.Length)
{
case 0:
break;
case 1:
_buff.Add(new State(state, next[0]));
break;
default:
foreach (LinkerNode nextNode in next)
_buff.Add(new State(state, nextNode));
break;
}
}
List<State> tmp = _variants;
_variants = _buff;
_buff = tmp;
if (_variants.Count == 0)
throw new ApplicationException("Unexpected segment: " + segName);
if (_variants.Count == 1)
ResolveQueue(_variants[0], segData);
else
_nonResolvedSegments.Push(segData.ToArray());
}
// _currentState.Count==1 or end of dataprivate void ResolveQueue(State state, IList<string> seg)
{
int[] path = state.Node.Descriptor.Path;
SegmentOrContainer e = _transaction[path];
if (e is IParseSegment)
{
(e as IParseSegment).Parse(seg);
}
else// impossible but just for a casethrow new InvalidOperationException(
"Internal linker error during resolve symbol: " + e);
if (_nonResolvedSegments.Count != 0)
ResolveQueue(state.PrevState, _nonResolvedSegments.Pop());
}
public void NotifyFinish()
{
// check for finish stateforeach (State variant in _variants)
{
if (variant.Node.IsFinishNode)
{
if (_nonResolvedSegments.Count != 0)
ResolveQueue(variant, _nonResolvedSegments.Pop());
return;
}
}
// linker is not in finish statethrow new ApplicationException("Unexpected end of transaction set segments");
}
}
}
В районе 3-6 мег в секунду как раз и дает, в зависимости от данных. Это из экспериментов и в продакшн не пошло. Входом имеет выход лексера, парсит дерево док-та, и одновременно линкует данные на его поля. Обрати внимание, что узлы графа вариантов GLR создается по new. Для макета покатит, для релиза нет. В продакшн варианте происходит все тоже самое, только в несколько раз больше кода, обыгрывающего низкоуровневую механику.
Так же обрати внимание, что алгоритм "оперативный", как только на некоем текущем участке if (_variants.Count == 1), т.е. все неоднозначности отмерли и осталась одна ветка, происходит линковка обработанной на данный момент части документа, и в самом док-те тоже совершаются прикладные всякие валидации. Оперативность позволяет немного уменьшить негативное влияние агрессивного использования GC на производительность. Сие влияние я расписывал по ссылке в пред. посте.
Фактически ~90% любого док-та парсится по одной ветке, т.е. вышеприведенный код на этих участках работает как ДКА, и его тормозит в основном дотнетный GC. Ну и самое главное, парсер завязан на прикладную специфику чуть менее чем полностью, только так затраты на парсинг удается свести к минимуму (после всей борьбы с GC, с применением тяжелой артиллерии в виде unsafe). K>Обсуждение технических моментов на словах ни к чему кроме понтов и не может привести. Я полагаю, здесь все не раз встречались с мастерами почесать языком.
Дудки, аналитику необходимо вывести "на кончике карандаша". Меня и почти всех моих знакомых коллег подробности чьей-то низкоуровневой механики не интересуют вообще, ибо сами с усами. Интересна исключительно суть алгоритма/алгоритмов. Не зря быстродействие парсеров измеряют в кол-ве посещений внутренних узлов на единицу длины входной цепочки. В реальной жизни запросто можно взять худший алгоритм, но за счет нивелилования выделения памяти из кучи получить лучший результат, чем хороший алгоритм, но реализованный на динамической памяти. Поэтому меня не столько интересовали их цифры, сколько подробности происходящего.
Здравствуйте, vdimas, Вы писали:
V>Почитал я сие "произведение"...
Этот GLR головного мозга и агония ужа на сковородке, хотя и изрядно веселит, но совершенно бесплодна. Разговор с совершенно не компетентным человеком вроде тебя цель которого сделать "хорошую мину при плохой игре" за счет оскорблений оппонентов и несения псевдонаучного бреда вроде "объяснения что алгоритм рекурсивного спуска (который мы используем) — это якобы на самом деле это восходящий анализ" мне не интересен. По сему лично я его прекращаю. Тебе тоже советую. Любое продолжение в том же духе будет воспринято мной как тролление, с твоей стороны, и будет караться соответствующим образом. Так же будет караться любые попытки унизить, оппонента с твой стороны. Так что советую остановиться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Этот GLR головного мозга и агония ужа на сковородке, хотя и изрядно веселит, но совершенно бесплодна. Разговор с совершенно не компетентным человеком вроде тебя цель которого сделать "хорошую мину при плохой игре" за счет оскорблений оппонентов и несения псевдонаучного бреда вроде "объяснения что алгоритм рекурсивного спуска (который мы используем) — это якобы на самом деле это восходящий анализ" мне не интересен. По сему лично я его прекращаю. Тебе тоже советую. Любое продолжение в том же духе будет воспринято мной как тролление, с твоей стороны, и будет караться соответствующим образом. Так же будет караться любые попытки унизить, оппонента с твой стороны. Так что советую остановиться.
Я не понял юмора. Ты решил в обмене любезностями оставить последнее слово за собой? Изволь сделать это без вот этих своих "изящностей" в слоге или через модераторскую вставку.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Элементарно. Берем два правила. Пускаем их по очереди (или параллельно) и смотрим кто из них съел большее количество входной строки. Кто съел больше, тот и папа.
V>Блин, всё время упускаю из виду эту "модульность". V>Понятно.
Это "модульность", а нисходящий анализ (рекурсивным спуском). Именно это дает возможность сделать каждое отдельное правило отдельным парсером. Модульность — это только один из следствий которые не сложно добиться. Для нас же важно не только то что мы можем добиться модульности, а то что мы можем относительно легко добиться динамической расширяемости. Динамическая расширяемость — означает, что мы можем менять грамматику на лету. При этом мы можем обеспечить весьма высокую скорость разбора для грамматик присущих современным языкам программирования. Никакие GLR-ы рядом не валялись. И, естественно, что подходы используемые в них для нас не применимы.
VD>>Если у нас PEG и мы поставим правила так: Х / У, то У с огромной вероятностью (а иногда на 100%) никогда не сможет сопоставиться. Оно просто будет всегда затенено.
V>Ну, это первое, за что ругают ПЕГ. Но как я понял из "ихних" форумов, такую ситуацию несложно валидировать автоматически еще на этапе построения парсера и выдавать ошибку.
Проверять затенение в общем случае невозможно (или слишком сложно для реальной жизни). Вольфхаунд, сейчас, хочет попробовать тупо заменить оператор приоритетного выбора на оператор предпочтения самого "длинного" правила (т.е. правила которое смогло распарсить большую по длине последовательность символов). Не уверен, что это хорошая идея. Но если он будет тормозить, то возможно, скоро мы сможем проверить его идею на практике.
V>Проскакивало еще мнение, близкое к обсуждаемому: задавать все правила как ИЛИ (т.е. как равнозначный выбор), затем выделять общие части после приведения, сортировать вхождения ИЛИ таким образом, чтобы самые длинные (поглощающие) подправила шли первыми, и заменять потом ИЛИ на приоритетное ИЛИ в стиле ПЕГ.
Я не понял зачем там что-то сортировать. И что значит "самые длинные (поглощающие) подправила". Правила тупо запускаются последовательно (или параллельно). При этом производится попытка разобрать все перечисленные по "|" правила (те что ранее были по "/").
V> Итого, самое длинное правило попытается быть разобранным самым первым, т.е. будут достоверно сохранены св-ва исходной грамматики, хотя будет использоваться техники разбора ПЕГ.
Это я понять не могу.
Что касается выделения "общих частей", то опять же напоминаю, что важное свойство создаваемого решния — динамическая расширяемость. Когда правила подгружаются во время разбора заниматься какими-то там вычислениями на грамматках и тем более генерировать код слишком дорого. Мы просто берем скомпилированные правила (которые являются подпарсерами) и помещаем их в массив.
Кроме того на этой же основе должен быть интегрирован алгоритм TDOP, который нужен для борьбы с левой рекурсией (а значит естественному описанию грамматики операторов) и ускорению разбора операторов в ЯП.
Вот, кстати, интеграция идей рекурсивного разбора с откатами и TDOP — это наше ноу-хау. По крайней мере я такого еще нигде не видел.
V>Но самое длинное правило не означает самую длинную цепочку.
Да вообще бессмысленно сортировать правила по длине грамматики. Вот в победе самого обжорливого правила смысл есть. По крайней мере это на 100% работает при выявлении ошибок. Скорее всего будет работать и для разрешения конфликтов.
По сути это очень похоже на GLR где идут параллельные разборы восходящим способом. Только вместо восходящего анализа используется нисходящий. По суются параллельные деревья разбора (если конечно грамматики неоднозначные), а выбор из них решается с помощью эвристики — выбор того при разборе которого парсер продвинулся дальше всего по строки. Расчет тут на то, что в 99% случаев альтернативы будут обламываться. Причем большая часть будет обламываться на первых символах. Так что реальный "выбор" (т.е. применение эвристики) будет происходить очень редко.
Тут есть огромное преимущество перед GLR. Мы строим дерево разбора в естественном для человека порядке. Это позволяет проще уложить ситуацию в мозг человека. Это приводит к тому, что фантомов (отбрасываемых правил) будет не так много.
VD>>Классика тупо не работает как надо. Она только на словах работает. А люди много десятилетий пишут парсеры языков вручную.
V>Только те, кто может себе позволить такие ресурсы. А так пишут на яках, бизонах, кокорах и прочих, коих много.
И получают непотребный результат. А те кто хочет получить качественный, и у кого (действительно) есть деньги или время, те паяют рукопашный парсер.
Вот мы и хотим положить этому конец. Наш генератор уже сейчас лучше рукопашных решений. А если идея Вольфхаунда окажется работоспособной, то возможно мы создадим прецедент и потомки будут смеяться над теми кто пишет парсеры вручную, так же как сейчас смеются над теми кто разбирает вручную то что можно разобрать регексами.
VD>>Эрли требует создания кучи динамических данных. VD>>Это не приминимый на практике алгоритм.
V>Применяют, с доработками. Не все грамматики укладываются в ограничения популярных техник парсинга.
Ламеры и неудачники его применяют. Ну, или исследователи которым просто плевать на скорость. Для реального разбора ЯП такие решения практически не применимы.
Ты тут много раз говорил про то что кто-то там "практически" не использует динамическую память. Вот Эрли ее требует.
VD>>Наш же алгоритм может жить вообще без динамического заема памяти. На практике мы занимаем память для циклических правил, чтобы накапливать результаты разбора. Но это не сильно влияет на производительность, так как там применяются динамические массивы. Да и на фоне создания АСТ это не такие уж и большие затраты.
V>Динамическое создание AST вообще не позволяет замерить собственную производительность парсера.
Сразу видно, что от практики ты далек. На практике создание АСТ занимает очень не много. Уж точно не основное время разбора. Так что если нет огромного количества откатов "больших" правил (т.е. правил которые формируют АСТ), то фактически время в пустую не тратится.
V>GC не может некоторое долгое время агрессивно выделять память, начинает заметно тормозить.
Может. Он на это и рассчитан. Надо только понимать, что у нас нет какого-то непроизводительного создания объектов. Все что создается надо на практике. Современные компиляторы всегда строят АСТ. А мы только на его создание память и тратим.
V>У меня недавно дошли руки погонять 4-й дотнет на предмет ускорения GC. Не особо. Результаты таковы: на коротком тесте простейший токенайзер, переводящий цепочки символов в String (без всяких вычислений) упирается в GC на уровне 100 МБ/сек.
К чему это зубопротезирование? 100 М/сек — это заоблачные цифры для парсеров. Если у нас будет разбираться C# или C++ со скоростью 50 метров в секунду, то это будет просто феерично и достаточно для риалтаймной работы с огромными проектами. На практике скорость выше 3 м/сек. уже достаточно для работы IDE.
V>А ведь машинка у меня довольно серьезная. Через 2 секунды первоначальный показатель падает вдвое, а еще через три секунды — втрое от первоначального, оставаясь потом на уровне ниже 28-29 МБ/сек.
Потому что это глупые синтетические тесты. На практике не надо молотить сотни метров за раз. Проекты разбиты на файлы. Файлы обычно не превышают сотни килобайт. Отдельные (обычно генерированные) доходят до 1-2 метров. Их АСТ несущественнен для GC.
В нашем парсере нет нужды материализовывать (превращать в строки) все "токены". Для "текстовых" правил, т.е. для правил не возвращающих АСТ мы отдаем только позицию начала и позицию конца. Можно или игнорировать их, или запоминать только их позиции. Большое же АСТ нужно по любому. Трата времени и памяти на него — это неизбежные затраты. Их просто глупо обсуждать.
V>Простое создание затем узлов АСТ на бинарных узлах попускает всё на уровень 8-12 МБ/сек. И это при том, что вообще никаких вычислений не происходит и подготовленные данные гоняются по кругу в памяти.
Очевидно ты тупо посадил GC на своп, так как тест совершенно не реальный. Реально компилятор того же немерла или шарпа трат на парсинг и создание АСТ меньше одного процента времени.
В современной интеграции Немерла при нажатии каждого символа запускается процесс парсинга с построением списка токенов, дерева токенов (свернутого по скобкам) и АСТ. И все это даже не заметно. А человек ведь может жать на кнопки довольно шустро. На таких объемах GC даже не замечает нагрузки.
V>Кол-во сохраняемых промежуточных токенов — не более 300к. Итого, дотнет позволяет на моей машинке работать примитивному токенайзеру со скоростью 250-300 МБ/с (если реультат не переводить в String и прочие АСТ), но при задействовании GC скорость падает до 8-12 МБ/с.
Код в студию, поглядим. Думаю что ты там что-то лажаешь. Скорее всего это голимая синтетика.
V>Вот почему я пользую пулы объектов даже в дотнете.
А какая разница занимать их перед разбором или во время? Или ты их переиспользуешь по сто раз?
V> И когда я в ответ на 4 MB/c с некоей иронией спрашивал, что же вы там замеряете, я имел ввиду не C#,
А ты прежде чем иронизировать попробовал бы найти другие парсеры которые обеспечивает такую же скорость способность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Не удержался. Можешь банить.
VD>несения псевдонаучного бреда вроде "объяснения что алгоритм рекурсивного спуска (который мы используем) — это якобы на самом деле это восходящий анализ" мне не интересен.
Ваш парсер модульный. Кое-какой тип "модуля" — это аналог лексера на ДКА. В процессе оптимизации в один такой ДКА может попасть более одного исходного правила, и даже целый иерархический куст оных из исходного дерева (из-за инлайна). И вот внутри этого ДКА-модуля никакого рекурсивного спуска при разборе соответствующего куста правил вы не используете. Это 100%, спроси у напарника. Мое предложение сводится к тому, чтобы этот выделенный модуль всего-навсего реализовать по другому алгоритму. Не зачем смущаться от того, что в этом относительно независимом модуле был предложен восходящий разбор, ибо парсинг регулярной грамматики по ДКА лексера — это тоже восходящий разбор. Сие тоже 100%, хоть режь, хоть бань. Да и пофиг в любом случае, какой он был до этого, коль модуль независимый и не вызывает в процессе работы другие модули.
Здравствуйте, WolfHound, Вы писали:
V>>Он нужен там, где и даром не нужно AST. Т.е. фактически везде, кроме узкой области компиляторостроения под ЯВУ. Для сравнения, компиляторов ЯВУ в активной разработке вряд ли больше нескольких сотен по всему миру (ну или единиц тысяч), а только лишь среду ANTLR качают по 5тыщ экземпляров в месяц. WH>Ну покажи мне что может это твое Parser tree чего не может мой парсер.
Parser Tree — это суть AST исходной грамматики, никакого rocket science. Я еще в самом начале "беседы" привел похожий сценарий, когда некие прикладные объекты читают свое состояние из XML. Популярны два сценария: чтение из "тяжеловесного" DOM или из легковесного SUX. Конкретно мой приведенный рядом сценарий очень похож с точностью до формата данных (вместо XML идут X12/EDIFACT/т.д.) Аналогично, как вместо DOM SUX-парсер выдает серии XML-path, по которым ходит в процессе разбора XML, так я имею цепочку ссылок на узлы исходного parser tree, т.е. цепочку применений правил. Конкретно в моей реализации, после серий упрощений "в уме", остались непосредственные ссылки на узлы НКА, по которым ходит автомат. Это просто такой бонус -1 на косвенность.
В общем, если нужен целевой объект AST (как у вас), то пусть AST. Если же AST у нас не целевой объект (а мне показалось, что этот макрос претендует служить как обобщенная парсерогенерилка, не только для расширения синтаксиса Немерле), то дополнительное промежуточное представление лишь нагружает GC.
Здравствуйте, vdimas, Вы писали:
V>В общем, если нужен целевой объект AST (как у вас), то пусть AST. Если же AST у нас не целевой объект (а мне показалось, что этот макрос претендует служить как обобщенная парсерогенерилка, не только для расширения синтаксиса Немерле), то дополнительное промежуточное представление лишь нагружает GC.
Остается выяснить где ты взял дополнительное промежуточное представление.
У меня его нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>В районе 3-6 мег в секунду как раз и дает, в зависимости от данных.
Это какая-то хрень полная, а не пример. О чем говорит пример, который даже запустить нельзя?
Из него не ясно вообще ничего. Ни какая грамматика, ни какие данные, ни как строится автомат.
Скорость опять же очень посредственная. Я уверен, Nemerle.Peg вполне способен выдать в разы больше на грамматике уровня сложности JSON.
V>Дудки, аналитику необходимо вывести "на кончике карандаша"
Бесполезная глупость.
V> В реальной жизни запросто можно взять худший алгоритм, но за счет нивелилования выделения памяти из кучи получить лучший результат, чем хороший алгоритм, но реализованный на динамической памяти.
Я даже больше скажу — "теоретически хороший" алгоритм в реальных условиях, на реальных данных и реальной компьютерной архитектуре может отсосать у "теоретически плохого".
Здравствуйте, Mamut, Вы писали:
M>Читаемость. Eof читаемее и понятнее, чем !Any. Учитывая отсутсвтие какой-либо стандартизованности предопределенных терминалов в PEG.
!Any это очень даже стандартно для ПЕГ.
А что такое eof не понятно. Особенно не понятно причем тут фаил если разбирается строка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Читаемость. Eof читаемее и понятнее, чем !Any. Учитывая отсутсвтие какой-либо стандартизованности предопределенных терминалов в PEG. WH>!Any это очень даже стандартно для ПЕГ.
Да ну? Где это оно стандартно? То, что оно вручную записывается и определяется обычно по типу Any = . не делает его стандартным
WH>А что такое eof не понятно. Особенно не понятно причем тут фаил если разбирается строка.
Какая разница? Никакой.
Кстати, что такое Any — тоже непонятно, потому что Any может зависеть от левой задней пятки автора грамматики и вообще неналичествовать в грамматике, потому что "." (Any) — это гораздо менее полезное правило, чем "!." (Eof)
Давал коллегам как подсказки/решения. 
