YOLO-JSON: знание — сила

Вот важная новость с фронта ИИ: rvetrin 14 минут назад YOLO-JSON: знание — сила Средний 19 мин 240 C++ * Кейс Всегда на проблему, до которой никому нет дела, найдется безумец с явно слишком большим количеством свободного времени. О такой проблеме мы сегодня и поговорим. Идея оптимизация парС++инга JSON выглядит в целом странной.

Если важна производительность, наверное будут выбраны другие инструменты для передачи данных. И, наверно, архитектор стороннего API, зная что его клиентам важна скорость, предоставит альтернативу в виде, например, gRPC. Казалось бы это абсолютно бесполезное занятие.

Технические детали

Но тем не менее у нас существует simdjson - великолепная библиотека, которая, пожалуй выжимает максимум производительности из доступного нам арсенала. Люди вложили огромный труд ради того, чтобы оптимизировать инструмент, который выбирают, когда производительность не так важна в целом. Давайте поддержим эту философию!

У меня есть опыт разработки выскочастотных систем и там становится очевидным следующая философия - "Настоящая С++корость является компромиссом с гибкостью решения". Самое быстрое решение скорее всего состоит только из компонентов, написанных специально для него. Если мы говорим о проблеме парсинга - идеальный инструмент должен уметь парсить только конкретный вид сообщения.

И именно поэтому я бы никогда не использовать simdjson в таких проектах - ведь это общее решение проблемы. Очевидно, что ради каждого вида сообщения писать свой парсер было бы безумием. В этой статье мы рассмотрим, какого компромисса мы можем достичь с применением новинок стандарта С++26.

Отраслевые последствия

Оглавление:КонцепцияРеализацияО рефлексииПарсинг значенийПарсинг аннотацийПарсинг массивовПарсинг JSONБенчмаркЗаключениеКонцепцияДостаточно очевидно, где мы можем ограничить общность решения. Если нам заранее доступна схема JSON и во всех ее вариациях, то мы на стадии компиляции можем составить оптимизированный план парсинга этого JSON. Более очевидно, что нам почти всегда известен объем памяти, который займет выходной объект, что позволяет статически зарезервировать нужный буфер.

Так же, если мы на стадии разработки подтвердили постоянство сообщений, нужно ли нам вообще формально валидировать JSON на боевой сборке? Внедрением именно этой логики и занимается написанный мною С++ фреймворк yolo-json. Название говорит само за себя - у вас появляется еще один способ выстрелить себе в ногу взамен на хороший компромисс между удобством и производительностью.

Мы будем интегрировать известные нам данные о приходящих JSON в наш код с помощью новых инструментов рефлекС++ии. Если СИЛЬНО утрировать, мы будем занимать примерно чем-то таким:char * curr = "{\"int\":1}"; assert(*curr == '{ curr++; assert(strncmp(curr, "\"int\":", 6)); curr += 6; int num = atoi(curr);Все просто - идем по строке и, зная какой формат JSON (с точным порядком полей и тому подобное) нас ждет, быстро передвигаемся по строке сразу к полям значений. На данном примере валидация сообщения происходит только в режиме отладки.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.