В репозитории очень много информации, и я с удовольствием вам ее предоставлю по бенчмаркам,
напишите, какие библиотеки вам бы хотелось увидеть, я подготовлю и напишу ответ. По поводу других, надо пробовать. И я признателен всем, кто дает мне фидбек.
UPD. До этого я пробовал и json2 и Jsoniter. json2 практически на ровне с стандартным. Jsoniter намного лучше, зависит от сценариев, но от нас отстает. Единственные кто может потягаться – simd типа sonic. Но у них есть свои большие недостатки и в ключевых сценариях благодаря многопоточности (и не только) у них мало шансов
*Тест последовательной десериализации сложной структуры с глубокой вложенностью, ~3 млн записей. Данные содержат экранированные строки, null-значения и неизвестные поля.
| Библиотека | Время (ns/op) | Пропускная способность | Память (B/op) | Аллокации (allocs/op) |
можете проверить. попытался сделать с SIMD на ваш процессор. На виртуалке скорость нет смысла тестировать. simdjson-go вообще arm не поддерживает, поэтому цифры там невалидные будут.
Совершенно верно. Но мы имеем то что имеем. Форматы не всегда мы выбираем. Это хорошо когда продукт не зависит от внешнего бизнеса. А внешнему бизнесу важнее другие вещи.
можно протестировать, но у меня графики линейные, и большого разлета не будет. Может просесть на процентов 30 в пике (если многозадачность не сработает). Но все равно это гораздо больше стандартных библиотек.
Очень хорошее замечание, но проблема не в анализе содержимого, а просто в том, что бы его получить. А так да, изменения тоже проверялись. На передачу данных мы никак повлиять не могли, увы.
насколько я помню, это экспериментальная версия, по крайней мере в 1.26.3 поэтому в репозитории она не присутствует. Но специально для ответа я провел тесты и получил
=== SilentJSON vs encoding/json v1 vs encoding/json/v2 (Go 1.26.3) ===
Вы абсолютно правы, тут всегда вопрос выбора инструмента под задачу.
Я пришел к этому решению через боль: когда нужно было каждый час парсить сотню прайсов от поставщиков (до 6 млн позиций на файл) для крупного портала, вопрос скорости парсинга стал критическим. Было обидно осознавать, что «бутылочное горлышко» — это не сложная бизнес-логика или нехватка мощностей, а именно сам парсер, который просто не успевал переваривать валидные данные. Причем ситуация усугублялась тем, что форматы у поставщиков были абсолютно разные и постоянно менялись.
Если бы такой инструмент был под рукой тогда, я бы сэкономил массу времени и нервов. В общем, как вы и сказали — «ружье» выстрелило именно там, где это было нужно для выживания проекта
Информация
В рейтинге
325-й
Откуда
Warszawa, Польша
Зарегистрирован
Активность
Специализация
Бэкенд разработчик, Архитектор программного обеспечения
по поводу
Интересует avx1 (aka avx-128) и neon в termuxна гитхабе можете создать таску. я включу в дорожную картукак вариант
go test -bench ./... -benchmemнет, поля могут меняться местами, лишние поля, непечатные символы
тут есть хитрость. Я кормлю их грязным json. а он видимо хорошо работает с чистым. Но это даже не смешно, если честно.
goos: windows goarch: amd64 pkg: github.com/GenshIv/silentjson cpu: AMD Ryzen 9 7950X3D 16-Core Processor
SilentJSON_Solo-32 | 298 | 3998580 ns/op | 3972.91 MB/s | 60544 B/op | 3 allocs/op
SilentJSON-32 | 1885 | 605436 ns/op | 26238.97 MB/s | 20791 B/op | 27 allocs/op
EasyJSON-32 | 21 | 55023176 ns/op | 288.71 MB/s | 66938179 B/op | 700019 allocs/op
go-faster/jx-32 | 63 | 19326083 ns/op | 822.00 MB/s | 15892560 B/op | 2 allocs/op
Standard_V1-32 | 9 | 121855689 ns/op | 130.37 MB/s | 10552349 B/op | 522219 allocs/op
PASS ok github.com/GenshIv/silentjson 8.954s
отдельно json v2 приведу из прошлого теста, бо там нужно включать экспериментальную поддержку
StdJSON_v1-32 3 80785100 ns/op 196.65 MB/s 2163085 B/op 220401 allocs/op
StdJSON_v2-32 3 82894933 ns/op 191.64 MB/s 19606984 B/op 820401 allocs/op
В репозитории очень много информации, и я с удовольствием вам ее предоставлю по бенчмаркам,
напишите, какие библиотеки вам бы хотелось увидеть, я подготовлю и напишу ответ. По поводу других, надо пробовать. И я признателен всем, кто дает мне фидбек.
UPD. До этого я пробовал и json2 и Jsoniter. json2 практически на ровне с стандартным. Jsoniter намного лучше, зависит от сценариев, но от нас отстает. Единственные кто может потягаться – simd типа sonic. Но у них есть свои большие недостатки и в ключевых сценариях благодаря многопоточности (и не только) у них мало шансов
1. BenchmarkNestedComparison
*Тест последовательной десериализации сложной структуры с глубокой вложенностью, ~3 млн записей. Данные содержат экранированные строки, null-значения и неизвестные поля.
| Библиотека | Время (ns/op) | Пропускная способность | Память (B/op) | Аллокации (allocs/op) |
| SilentJSON |
790,308,800| 640.23 MB/s |65,368,888| 6 || Sonic |
1,203,687,900| 420.36 MB/s |886,626,392| 10,612,816 || Jsoniter |
1,490,925,000| 339.37 MB/s |2,045,419,120| 28,434,294 || Simdjson |
1,720,019,800| 294.17 MB/s |5,742,331,784| 21 || Buger/jsonparser |
3,430,657,000| 147.49 MB/s |511,510,464| 26,433,913 || Standard |
4,815,193,900| 105.08 MB/s |162,149,888| 13,343,235 |2. BenchmarkLargeScaleComparison
*Десериализация большого массива, состоящего из 100 000 объектов
| Библиотека | Время (ns/op) | Пропускная способность | Память (B/op) | Аллокации (allocs/op) |
| SilentJSON |
6,113,900| 2598.34 MB/s |19,189,576| 24,472 || SonicParallel |
11,889,000| 1336.19 MB/s |55,370,048| 569,222 || Sonic |
34,034,900| 466.76 MB/s |16,217,376| 10,004 || Protobuf (для сравнения) |
35,280,500| 192.91 MB/s |39,120,520| 1,100,019 || Simdjson_AST |
56,378,700| 281.77 MB/s |180,495,912| 17 || Buger/jsonparser |
107,575,500| 147.67 MB/s |20,807,936| 1,099,990 || Standard |
164,591,500| 96.52 MB/s |3,904,224| 509,997 |как то так
я внес правки в статье в соответствии с данными
Справедливо, я не корректно поставил информацию. Вернее было бы считать не мегобайты, а сколько объектов у нас распарсилось.
BenchmarkLargeScaleComparison/SilentJSON-32 241 5076327 ns/op 3129.43 MB/s 82334 B/op 132 allocs/opBenchmarkLargeScaleComparison/Protobuf-32 36 32726719 ns/op 207.96 MB/s 39120496 B/op 1100019 allocs/opвидим 241 против 36 проходов абсолютно одинаковых наборов. можете сами протестировать на своих данных
можете проверить. попытался сделать с SIMD на ваш процессор. На виртуалке скорость нет смысла тестировать. simdjson-go вообще arm не поддерживает, поэтому цифры там невалидные будут.
UPS немного отладки еще нужно. скоро выложу
Совершенно верно. Но мы имеем то что имеем. Форматы не всегда мы выбираем. Это хорошо когда продукт не зависит от внешнего бизнеса. А внешнему бизнесу важнее другие вещи.
справедливо, я добавил сравнение, не полное, но смысл понятен в описании в гите подправил график и табличку красивее. файлики по 5 записей.
LibraryThroughput (MB/s)Latency (ns/op)Memory Allocated Allocs/op
SilentJSON (Parallel) 735.98MB/s 877.7ns 25B 1
Sonic 317.21MB/s 2036ns 2632B 21
Standard (
encoding/json) 84.61MB/s 7635ns 2528B 52можно протестировать, но у меня графики линейные, и большого разлета не будет. Может просесть на процентов 30 в пике (если многозадачность не сработает). Но все равно это гораздо больше стандартных библиотек.
я могу дополнить для вашей платформы поддержку, если напишите какую. Более того, буду благодарен, если поможете протестировать в своих условиях
Очень хорошее замечание, но проблема не в анализе содержимого, а просто в том, что бы его получить. А так да, изменения тоже проверялись. На передачу данных мы никак повлиять не могли, увы.
насколько я помню, это экспериментальная версия, по крайней мере в 1.26.3
поэтому в репозитории она не присутствует. Но специально для ответа я провел тесты и получил
SilentJSON-32 1 753595900 ns/op 671.42 MB/s 65368888 B/op 6 allocs/opStdJSON_v2-32 1 2698572700 ns/op 187.50 MB/s 1985055064 B/op 18910718 allocs/opStdJSON_v1-32 1 3108066300 ns/op 162.80 MB/s 1985062216 B/op 18910832 allocs/op— Unmarshal 100K records (parallel) —
SilentJSON_Parallel-32 3 4823467 ns/op 3293.48 MB/s 6021384 B/op 163 allocs/opStdJSON_v1-32 3 80785100 ns/op 196.65 MB/s 2163085 B/op 220401 allocs/opStdJSON_v2-32 3 82894933 ns/op 191.64 MB/s 19606984 B/op 820401 allocs/op— Marshal 100K records —
SilentJSON-32 3 11557700 ns/op 1409.30 MB/s 0 B/op 0 allocs/opStdJSON_v2-32 3 40116033 ns/op 396.00 MB/s 15892528 B/op 3 allocs/opStdJSON_v1-32 3 41471367 ns/op 383.06 MB/s 15892528 B/op 3 allocs/op— Stream Decode 3M records (482 MB JSON) —
SilentJSON_Stream-32 1 836256500 ns/op 605.05 MB/s 41405248 B/op 7714289 allocs/opStdJSON_v2_Stream-32 1 2917844500 ns/op 173.41 MB/s 1985114304 B/op 18910791 allocs/opStdJSON_v1_Stream-32 1 3703443800 ns/op 136.62 MB/s 106551440 B/op 5118604 allocs/opВы абсолютно правы, тут всегда вопрос выбора инструмента под задачу.
Я пришел к этому решению через боль: когда нужно было каждый час парсить сотню прайсов от поставщиков (до 6 млн позиций на файл) для крупного портала, вопрос скорости парсинга стал критическим. Было обидно осознавать, что «бутылочное горлышко» — это не сложная бизнес-логика или нехватка мощностей, а именно сам парсер, который просто не успевал переваривать валидные данные. Причем ситуация усугублялась тем, что форматы у поставщиков были абсолютно разные и постоянно менялись.
Если бы такой инструмент был под рукой тогда, я бы сэкономил массу времени и нервов. В общем, как вы и сказали — «ружье» выстрелило именно там, где это было нужно для выживания проекта