[HN Gopher] Sonic: A fast JSON serializing and deserializing lib...
___________________________________________________________________
Sonic: A fast JSON serializing and deserializing library
Author : ngaut
Score : 27 points
Date : 2021-11-21 15:02 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| throwaway889900 wrote:
| Seems like it's similar in performance to Jackson?
| BeeOnRope wrote:
| Just another case where a library tests and publishes results for
| all competing libraries _slower_ than it, but none faster.
| _cough_ simdjson [1] _cough_
|
| ---
|
| [1] https://github.com/simdjson/simdjson
| [deleted]
| nemothekid wrote:
| simdjson is listed thought.
| memco wrote:
| It is mentioned here: https://github.com/bytedance/sonic/blob
| /a577eafc253adb943924..., but it isn't included in the
| benchmarks graphs. Seems this repo is specifically focused on
| Golang and isn't necessarily motivated by being the fastest
| JSON [de]serializer on the planet.
| craigching wrote:
| There is this one though:
| https://github.com/minio/simdjson-go
| TheMagicHorsey wrote:
| It seems its mostly written in assembly? I'd be worried about
| portability, maintainability, and security.
|
| I'd be way more comfortable if it was written in C, or better yet
| Rust.
| scottlamb wrote:
| It sounds like it essentially is written in C. INTRODUCTION.md
| says:
|
| > As for insufficiency in compiling optimization of go
| language, we decided to use C/Clang to write and compile core
| computational functions, and developed a set of asm2asm tools
| to translate the fully optimized x86 assembly into plan9 and
| finally load it into Golang runtime.
|
| Github says it's 59.6% assembly and 6.5% C. Possibly the
| assembly is just the checked-in result of compiling+translating
| the C?
|
| Gross that they have to do this. I know the Go folks really
| prioritize speed of compilation, but I wish they'd support
| debug builds with their own backend and release builds with
| LLVM so you could get this kind of performance when actually
| writing Go. I see there have been a few attempts at Go +
| general-purpose backend (gccgo, llgo, gollvm) but none seem to
| use the official Go frontend written in Go, so I think they're
| doomed to be second-class at best.
|
| edit: and/or, if the Go folks and GCC and/or LLVM coulds could
| negotiate a shared ABI (not necessarily switching to the
| platform's default C ABI but having "cc --abi=special-golang-
| stack-copying-thing"), folks could just link against something
| compiled in C/Rust/whatever without requiring this separate
| compilation+translation step (the high-maintenance, high-
| performance path) or CGo overhead (the easy but slow-for-
| frequent-calls path).
| latchkey wrote:
| I really don't care what language it is written in. As long as
| there is full test coverage, I'm happy.
|
| I've been a long time user of jsoniter and it is much faster
| than the standard lib. It really makes a difference for the
| work I do. If this is even faster and has tests, even better.
| uncomputation wrote:
| Since when is 635 KB "large"? I suppose it depends on your use
| case, since they consider 400 B a small, they probably use lots
| of JSON APIs for many small things.
| unspecified wrote:
| Small (400B, 11 keys, 3 layers) Medium (13KB, 300+ key, 6
| layers) Large (635KB, 10000+ key, 6 layers)
|
| I would be so happy to work somewhere where a 0.000635 GB json
| file is "large".
___________________________________________________________________
(page generated 2021-11-23 23:00 UTC)