|
|
|
Yacc или самописный парсер?
|
|||
|---|---|---|---|
|
#18+
Вопрос в скорости. Есть у меня проект с языком. На C#, что важно. Сейчас лекс. и синт. разборы написаны самостоятельно, с использованием возможностей языка. В частности, дерево разбора строиться с использованием набора мелких методов, каждый метод на свое синт. правило. Такой метод получает в параметре узел "предыдущего" дерева, в начале создает "свой" узел дерева, далее смотрит лексемы и, в соответствии с правилом, передает этот "свой" узел (уже как "предыдущий") схожим методам для подчиненных правил, которые строят ветки дерева от "своего" узла. Если все отработало нормально, то "свой" узел (уже вместе в ветками) добавляется в "предыдущее" дерево, возвращается ОК. А если какое несоотвествие правилу - ничего в "предыдущее" дерево не добавляем, возврашаем "ошибку". Ненужные "свои" узлы оставляем для сборщика мусора. Узлы, кстати, - специфичные для правил объекты, каждыей со своим функционалом, на них все последующее исполнение завязано. В общем свое построено на вызове методов (возможно рекурсия), дерево строится паралельно росту стека. Вроде как все используют Yacc. Есть его модификация под С#. Технология типа отшлифована 10-летиями. Насколько на Yacc процесс разбора эффективнее? На текущий момент меня пока всё устраивает, но если с Yacc будет сильно быстрее , то надо будет копать туда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 10:18 |
|
||
|
Yacc или самописный парсер?
|
|||
|---|---|---|---|
|
#18+
IzyaВопрос в скорости. Есть у меня проект с языком. На C#, что важно. Сейчас лекс. и синт. разборы написаны самостоятельно, с использованием возможностей языка. В частности, дерево разбора строиться с использованием набора мелких методов, каждый метод на свое синт. правило. Такой метод получает в параметре узел "предыдущего" дерева, в начале создает "свой" узел дерева, далее смотрит лексемы и, в соответствии с правилом, передает этот "свой" узел (уже как "предыдущий") схожим методам для подчиненных правил, которые строят ветки дерева от "своего" узла. Если все отработало нормально, то "свой" узел (уже вместе в ветками) добавляется в "предыдущее" дерево, возвращается ОК. А если какое несоотвествие правилу - ничего в "предыдущее" дерево не добавляем, возврашаем "ошибку". Ненужные "свои" узлы оставляем для сборщика мусора. Узлы, кстати, - специфичные для правил объекты, каждыей со своим функционалом, на них все последующее исполнение завязано. В общем свое построено на вызове методов (возможно рекурсия), дерево строится паралельно росту стека. Вроде как все используют Yacc. Есть его модификация под С#. Технология типа отшлифована 10-летиями. Насколько на Yacc процесс разбора эффективнее? На текущий момент меня пока всё устраивает, но если с Yacc будет сильно быстрее , то надо будет копать туда. Ни фуфа не эффективнее. Когда GCC отказался от bison'а, то у них на 1.5% быстрее работать стало, да ещё и плюшки как из рога изобилия посыпались: https://gcc.gnu.org/wiki/New_C_Parser Ни фуфа не все используют. clang тоже RDP . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 10:25 |
|
||
|
Yacc или самописный парсер?
|
|||
|---|---|---|---|
|
#18+
Izya, рекурсивный спуск называется -если устраивает - не трать силы, оставь как есть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 11:00 |
|
||
|
Yacc или самописный парсер?
|
|||
|---|---|---|---|
|
#18+
Когда я пытался на Yacc/Lex описать относительно сложный синтаксис (подмножество Oracle Sql, Pl/Sql). Получилось, что после "парсинга" Yacc/Lex нужно куда-то результаты разбора складывать, для последующей обработки. Что вроде и логично ))), а на деле с yacc/lex кода нифига не меньше, чем "ручками" разбирать. Правда проект до конца был не доведен. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 15:39 |
|
||
|
Yacc или самописный парсер?
|
|||
|---|---|---|---|
|
#18+
1.5% это мощно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 17:00 |
|
||
|
Yacc или самописный парсер?
|
|||
|---|---|---|---|
|
#18+
IzyaВроде как все используют Yacc. Есть его модификация под С#. Технология типа отшлифована 10-летиями. Насколько на Yacc процесс разбора эффективнее? На текущий момент меня пока всё устраивает, но если с Yacc будет сильно быстрее , то надо будет копать туда.Пока ты не попробуешь повторить свой парсер на Яке и не погоняешь оба варианта на множестве тестов - ты не узнаешь что эффективнее. Мы тем более не сможем сказать что эффективнее - твой парсер или широко известный. Люди используют Яков-Бизонов когда им лениво писать свой собственный парсер. Или если возможностей этих широко известных парсеров не достаточно для разбираемого языка. Например если для языка невозможно сочинить CFG, то придется писать свой парсер. Во всех остальных случаях: либо лениво - либо нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 18:23 |
|
||
|
Yacc или самописный парсер?
|
|||
|---|---|---|---|
|
#18+
On 11.06.2014 16:39, Leonid Kudryavtsev wrote: > обработки. Что вроде и логично ))), а на деле с yacc/lex кода нифига не > меньше, чем "ручками" разбирать. Правда проект до конца был не доведен. Я бы сказал, не что он меньше или больше, а что существование этого кода вообще возможно, и код этот поддерживаемый. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 18:26 |
|
||
|
Yacc или самописный парсер?
|
|||
|---|---|---|---|
|
#18+
Большие LALR парсеры на yacc/bison сложно отлаживать и легко сломать при расширении. Если в разбираемом языке синтаксис зависит от контекста, то код LALR парсера обрастает огромным количеством хаков для реализации этой зависимости. Самописный рекурсивный спуск намного проще в сопровождении и отладке. Будет ли он работать быстрее зависит от того насколько вы наловчились писать такие парсеры :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.06.2014, 22:55 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=38668192&tid=1341327]: |
0ms |
get settings: |
11ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
178ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 504ms |

| 0 / 0 |
