Ну у чисто луёвых либ есть одно фундаментальное ограничение под названием "строчки иммутабельны", посему при всей работе со строчками (те же чтения буферов из сокетов или ещё что) крайне желательно ничего с ними не делать, как получил так и работай (а это обычно замороченно жестб, учитывая что какой-нибудь циклический буфер с константным потреблением памяти не сделаешь без сишки). И вызов функций а ля str:byte(i, i) тоже медленнее чем с сишной стороны.
Но это фундаментальное ограничение, которое будет в любом случае пока мы не влезем глубже.
мм. Там по-разному было. Иногда cjson был медленнее resty-simdjson, а иногда быстрее. Но lua-simdjson в любом случае быстр был.
По практике нам тоже всё устроило. Чуток отличается поведение в парсинге только. Типа опции конфигураций у cjson больше.
Ну и cjson никуда не делся, потому что у simdjson iirc нет encode, только decode
Когда разница на порядок-два — тут типа уже вполне думаемо.
Но это мои условия, обычно некуда сильно спешить во-первых, а во-вторых, вокруг как правило ещё мно-о-о-ого разного кода который нивелирует эти скорости парсинга джейсонов до 5% от общей деятельности, и "ускорение парсинга джейсона вдвое" обычно означает "подъём общей производительности на 2.5% — жрал 5%, стал жрать 2.5%".
И это не учитывая собственно лимитов по скоростям чтения с диска например.
А если жсоны ещё и однотипны, и имеют конкретную структуру и из них нужны только конкретные поля, можно вообще всё нафиг хакнуть и парсить их луёвыми паттернами (а то и вовсе парой string-find'ов с отключёнными паттернами, тот умеет в чистый strcmp), что как раз обычно ускоряет на пару-тройку порядков, за что можно шевелиться при необходимости.