OP
нет там последовательных сравнений
Size: a a a
2021 November 18
VO
ну на фоне остального перла наверное разницы заметно не будет, но...
OP
на каждый символ входной строки он проходит ровно 1 транзишен из стейта в стейт
NK
о чем вы тут спорите? Там же подмножество регекспов, их в мире куча разных реализаций и многие для подмножества быстрее чем полновесное перловое
VO
ну и как там делается a|x|k|t
NK
а для разбора роутов тем более очень узкое подмножество
NK
и O(n) вполне логично
OP
для разбора роутов - да, но там под капотом полноценный я не стал оптимайзить под роуты пока.
NK
и картинка выше вообще на первый взгляд напоминает подход как в стековых машинах
NK
ну вот если оно полноценно то было бы интересно почитать большую пдф-ку про разницу подходов и как оно получилось быстрее
VO
я где-то спорил что можно быть быстрее перловых регэкспов? я только спорю что от регэкспа скорость работы не зависит мол вообщевообще
OP
и он реализован одним из возможных вариантов щас, который память кушает прилично (на роутер из 700 урлов, примерно 5 мегабайт)
NK
в юри::роутер? 5 мегабайт на 700 урлов?
OP
но это связано с тем что в рантайме нет компиляции. с jit или inline::c потом в беклог себе положил сделать альтернативу, которая память почти не жрет и работать должно в несколько раз быстрее (эта реализации уже может слегка реагировать на кол-во и состав регэкспов, но в любом случае будет быстрее чем текущая)
OP
да, сейчас килобайт на стейт в DFA, там таблица транзишенов
OP
в 700 урлах которые там в бенмарке в модуле лежат 5к+ стейтов
OP
но это регэксп гигансткого масштаба, сам регэксп килобайт 40 занимает
OP
но обычно в проектах даже крупных кол-во роутов не превышает 1000
NK
а, DFA это оказывается конечные автоматы.
NK
впервые кажется вижу как они на английском называются