Comments 9
Мне кажется или это задача сериализатора, который должен бегать по мета-информации полей объектов, помеченных как чувствительные? И тогда не надо делать пост-процессинг.
Два маленьких замечания, которые сразу приходят в голову.
Лучше сравнивать с blacklist, который в реальной жизни должен быть гораздкорочече, чем whitelist.
Надо завести boolean переменную, было ли хоть одно удаление. Если еще не было ни одного, то и записывать ничего не надо.
Спасибо за фидбек, могу сказать что:
Решение с whitelist до сих пор вызывает споры у нас самих - blacklist был бы намного проще в использовании и прощал бы нам многие ошибки, например, мы могли бы хуже следить за соответствием DSL описания API на стороне сервиса и на стороне транспорта и пропускать ошибки, связанные с кодогенерацией. Whitelist накладывает на нас более жёсткие требования в отношении корректности описаний. А поскольку мы прекрасно понимаем, что это всё - костыль, а костыль гнуться не должен - мы выбрали вариант с whitelist.
Про булевский флаг не очень понял, но в целом у нас уже сейчас в документ не вносятся никакие изменения, если не надо (он даже не копируется внутри памяти).
Blacklist потенциально более опасен в плане утечки информации: добавили новый тег и забыли добавить его в блеклист. В случае с белым списком подобная ошибка не приведёт к утечке данных, а поломает функционал, что, скорее всего, сразу будет замечено.
выдаёт производительность чуть меньше 10 гигабит в секунду на одном ядре
А многопоточный режим тестировали? Лидер вполне мог смениться.
Ещё мне кажется, что однопроходный алгоритм потенциально более производительный, по каким-то причинам не получилось "скрестить" его с кодом simdjson?
А там, где этот код использовался в дальнейшем - есть несколько потоков, в котором обрабатываются данные и один из этапов фильтрация json. Плодить лишние потоки ради одного этапа - с большой вероятностью уменьшить общую производительность. В любом случае насколько я знаю, никто не пытался расспаралелить алгоритм.
А насчет однопроходности: в первом проходе используется AVX2 для разбора и по моим тестам, чем больше идёт подряд AVX2 команд с последовательной обработкой данных - тем быстрее получается. А во втором AVX2 использовать не получилось, там приходится обходить дерево, "прыгать" по данным туда сюда с кучей условий. А это не очень удобно на AVX делать, поэтому вынесли во второй проход.
В любом случае насколько я знаю, никто не пытался расспаралелить алгоритм.
нет, я совсем не это имел в виду.
речь про то, что суммарная производительность многих инстансов совершенно необязательно линейно соотносится с производительностью одного инстанса, например, один может полностью выбирать ПСП и с ростом числа потоков производительность перестанет расти.
Однопоточность была у нас исходным требованием для конкурса. Естественно в реальности у нас не одна труба для данных и такие однопоточные алгоритмы обрабатывают свои потоки данных параллельно в разных потоках суммарно обеспечивая кратную пропускную способность. Про многопоточную фильтрацию одного документа мы тоже думали, но решили, что большого бонуса нам это не даст - кажется, это может уменьшить latency для обработки документов (и то я сомневаюсь), но общая пропускная способность может снизится. При этом добавляемый однопоточной фильтрацией latency на общем фоне и так исчезающе мал. Но если честно, мы с самого начала хотели подтолкнуть разработчиков к использованию векторных инструкций, а допустив многопоточный парсинг рисковали бы отправить их по ложному пути :)
Фильтрация JSON: как мы проводили конкурс на самый быстрый алгоритм