Так вот, почему ж парсер неэффективный-то

Начать стоит с того, что они по одному и тому же запросу проходятся дважды. Это такая особенность их парсера: сначала разбиваем на токены, потом уже производим основные манипуляции. Зачем это нужно? Я не знаю. А поэтому, и не берусь судить. Но да, это неэффективно, и можно было лучше

Продолжим тем, что у них примерно та же штука, что и у меня когда-то в парсере было. А именно - диспатчинг. Другими словами - у парсера есть состояние, и цикл, который проходит по сырому запросу. И на каждой итерации этого цикла, мы заново через свитч проверяем состояние парсера. Это неэффективно, потому что мы внутри всегда знаем, куда нам надо дальше (да, безусловные переходы с гото), а с их подходом - мы делаем кучу ненужных свитч-кейсов. Которые, хоть и по инту, но все же в сумме стоят весьма дорого - проверил на личной шкуре.

Замечание: на безусловных переходах полностью от диспатча и состояния не уйти, он все равно будет нужен при вызове функции, чтобы прыгнуть туда, где парсер в прошлый раз остановился. Но это стоит практически ничего

Замечание 2: раньше в парсере, при каждом безусловном переходе я заодно записывал новое состояние в поле структуры. Избавился, тем самым сэкономив пару лишних mov, посредством записи состояния только при выходе (при этом, успешного) из функции

Замечание 3: можно сильно удешевить диспатчинг, не прибегая к гото (если такая задача стоит). Достаточно просто взять ту же схему, что и с гото, когда каждый блок полностью автономно парсит свою часть запроса, и дальше уже передает управление туда, куда следует. Тобишь, в таком случае - у нас сильно уменьшается как количество состояний (что позитивно влияет на размер свитч-кейса, количество сравнений, работу бранч-предиктора, функция лучше в кэш помещаться будет, и т.д.), так и упрощается сам код. Получится такая штука, что в каждом состоянии мы парсим отдельную единицу запроса (например - метод, путь запроса, ключ заголовка, и т.п.), и только после этого выполняем повторный диспатчинг, чтобы перейти к следующему участку кода. Таким образом, у нас все еще остаются некоторые затраты на свитч, но они сильно минимизируются на фоне остального