Кхе. А ты думаешь это реально? Я что-то не встречал алгоритмов перевода из псевдокода инструкций в дерево.
а! вот про это я и твержу тебе! с псевдокодом и инструкциями работать уже поздно, работать надо сразу с правилами. потому что правила в дерево свернуть реально, а псевдокод -- уже заипешься. потому и говорю, что термин алгоритмическая оптимизация тут неверный, тут не оптимизация псевдокода идет.
а построение дерева из правил -- да, реально. и как мне кажется даже не очень сложно, даже с учетом абстракций. т.е. да, первоначальный кусок будет довольно трудоемкий, но зато потом все будет на несколько порядков быстрее и легче.
никакого произвольного набора полей, а тем более строк или даже регэксопв для SIP, там и близко нет. Такая тема тянет на докторскую, пожалуй =) Сочинить такое своё я пожалуй точно ниасилю.
да нет, вроде ничего особо сложного нет. тем более докторской, ведь аналитически исследовать не требуется. а если посмотреть на текущий код raidix tree для роутинга (в которм закодированны комманды посмотреть бит по смещению x и которе реально ничего не знает про протокол, который роутит, там даже таблицы виртуальных методов нет на момент роутинг лукапа) то в общем-то это уже и так почти готовое "по произвольному набору полей". ну и вот hipac -- на самом деле о том же самом, то что там нет произвольного набора -- это проблема фронтенда, сам-то механизм именно что по произвольному набору работает. т.е. надо различать проблемы собственно лукапа и построения дерева для работы этого лукапа. ну со строками отдельный момент, их надо вторым эшелоном пускать, видимо.
no subject
Date: 2012-05-25 06:18 am (UTC)а! вот про это я и твержу тебе! с псевдокодом и инструкциями работать уже поздно, работать надо сразу с правилами. потому что правила в дерево свернуть реально, а псевдокод -- уже заипешься. потому и говорю, что термин алгоритмическая оптимизация тут неверный, тут не оптимизация псевдокода идет.
а построение дерева из правил -- да, реально. и как мне кажется даже не очень сложно, даже с учетом абстракций. т.е. да, первоначальный кусок будет довольно трудоемкий, но зато потом все будет на несколько порядков быстрее и легче.
да нет, вроде ничего особо сложного нет. тем более докторской, ведь аналитически исследовать не требуется. а если посмотреть на текущий код raidix tree для роутинга (в которм закодированны комманды посмотреть бит по смещению x и которе реально ничего не знает про протокол, который роутит, там даже таблицы виртуальных методов нет на момент роутинг лукапа) то в общем-то это уже и так почти готовое "по произвольному набору полей". ну и вот hipac -- на самом деле о том же самом, то что там нет произвольного набора -- это проблема фронтенда, сам-то механизм именно что по произвольному набору работает. т.е. надо различать проблемы собственно лукапа и построения дерева для работы этого лукапа. ну со строками отдельный момент, их надо вторым эшелоном пускать, видимо.